321–330 of 504 posts
TLS termination is still not working for HTTP/3, I think. The nicest feature of HTTP/3 is that it is UDP based, and thus does not allow so much interception by the malicious ISPs.
Earlier quoted context omitted.
More than just that it came from MS. For a long time, .NET was completely proprietary, and only ran on Windows. Now it is open source and cross platform, but it is still fighting the momentum of being seen as Windows-only.
Can you name some examples of popular .Net applications on GNU/Linux or *BSD operating systems?
But that's not really what's being discussed in the context of this thread: application servers handling HTTP/3.
Earlier quoted context omitted.
What kind of overhead? I’m curious if there’s data about this because I hadn’t heard that 1.1 was better for the data center.
QUIC/HTTP3 relies on TLS. If you already have some encrypted transport, like an Istio/Envoy service mesh with mutual TLS, or Zerotier/Tailscale/Wireguard style encrypted overlay network, then there are no benefits to using HTTP3. Moreover native crypto libraries tend do a better job handling encryption anyway so rather than wasting cycles doing crypto in Go or Node it makes more sense to let the service mesh or the o…
which could use HTTP/2 or HTTP/3
and HTTP/2 for the localhost (or unix socket) gatewayapp step to provide e.g. WebTransport support
Earlier quoted context omitted.
"It's not being used", except for nearly half of Google's traffic: https://www.google.com/intl/en/ipv6/statistics.html Disconnect your phone from Wi-Fi and visit https://ifconfig.co/ . If you're a Verizon customer, it's probably going to show you an IPv6 address. It's huge, right now, today.
"Depended on" is what I should have said. An ISP or website can be v4-only or support both, but it's not going to be v6-only.
Earlier quoted context omitted.
It's not about different teams, it's that System.Windows.Forms is exactly what the namespace says. It's Windows Forms. It's a fairly thin wrapper over the Windows API. It's never going to be adapted to be cross-platform and isn't really something they've put any development work into for many years at this point. If you want a cross platform UI, use WPF with Avalonia. Or if you want something entirely from Microsoft…
obviously system.windows.forms could easily be implemented elsewhere, but okay, does any of the other UIs work fully properly on for example linux?
Earlier quoted context omitted.
Can you please highlight some examples of .NET’s lackadaisical security record? I’m curious for my own awareness.
Microsoft's. Consult your favorite search engine.
Earlier quoted context omitted.
> And it turns out that TS is syntactically and semantically much closer to Go, so you can often convert the former to the latter mechanically. Are there examples of this? I ask because I've been working on a Nest.js backend in TS and it's remarkably similar to C# .NET Web APIs (controllers, classes, DI). Really curious to see the translation from TS to Go.
TSC codebase is quite unlike regular TypeScript code you will see out there. So it is about specific way TSC is written in being the easiest to port to Go rather than the TS language as a whole. There's a screenshot comparing the two side-by-side, IIRC it was showcased on the video of the talk (if someone has a timestamp - please post).
Earlier quoted context omitted.
I'm not an expert on HTTP/3, but vehemently disagree about IPv6. It removes tons of overhead and cruft, making it delightful for datacenter work. That, and basically guaranteeing you don't have to deal with the company you just acquired having deployed their accounts with the same 10/16 subnet your own company uses.
> It removes tons of overhead and cruft Can you elaborate? Here, or with links? What kinds of overhead and cruft?
* You can't fragment packets.
* The redundant checksum header was removed.
* No more private addressing (unless you're a glutton for punishment).
* No more NAT (see above).
* Simpler routing.
* Doesn't require DHCP.
It benefits hugely from the lessons learned with IPv4.
Earlier quoted context omitted.
"Depended on" is what I should have said. An ISP or website can be v4-only or support both, but it's not going to be v6-only.
Fair. I bet that'll change soon though. My prediction is that it'll be a mobile-first game, like the next Pokemon Go sort of thing, that'll be IPv6-only.
Earlier quoted context omitted.
QUIC/HTTP3 relies on TLS. If you already have some encrypted transport, like an Istio/Envoy service mesh with mutual TLS, or Zerotier/Tailscale/Wireguard style encrypted overlay network, then there are no benefits to using HTTP3. Moreover native crypto libraries tend do a better job handling encryption anyway so rather than wasting cycles doing crypto in Go or Node it makes more sense to let the service mesh or the o…
> let the service mesh or the overlay handle encryption which could use HTTP/2 or HTTP/3 and HTTP/2 for the localhost (or unix socket) gateway app step to provide e.g. WebTransport support