Live data from Hacker News

HTTP/3 is everywhere but nowhere

httptoolkit.com

51–60 of 504 posts

Re: HTTP/3 is everywhere but nowhere

#51
post #13
post #10

Every single project mentioned in the article is to some extent either open source and/or community driven. So nobody considered HTTP/3 interesting enough to rush and add support for it very quickly. It'll get there, but fast? I don't think so, see IPv6. Also, nobody considered HTTP/3 worth enough of paying for maintainers to add support for it.

Nginx (F5) and Go (Google) are hardly scrappy open source projects with limited resources. The former is semi-commercial, you can pay for Nginx and still not have stable HTTP3 support. Google was one of the main drivers of the HTTP3 spec and has supported it both in Chromium and on their own cloud for years, but for whatever reason they haven't put the same effort into Go's stdlib.

I'd go with HAProxy over Nginx any day. It far more robust and more capable. They've had QUIC & HTTP/3 since 2022.

Re: HTTP/3 is everywhere but nowhere

#53
post #29

If you are looking for a reverse proxy with good HTTP/3 support, I recommend Envoy. Configuring it is a bit of a chore, but it feels like it was engineered from first principles to be the best possible HTTP/2 and 3 reverse proxy. The architecture for HTTP is entirely based around the h2 protocol, unlike NGINX which splits requests into various phases and struggles to support things like bidirectional streaming and up…

Why not Traefik?

Re: HTTP/3 is everywhere but nowhere

#54

> At the same time, neither QUIC nor HTTP/3 are included in the standard libraries of any major languages including Node.js, Go, Rust, Python or Ruby. .NET actually looking like it has decent support for any teams that are interested[0] (side note: sad that .NET and C# are not considered "major"...). There is an open source C library that they've published that seems rather far along[1] Support for Windows, Linux[2],…

> side note: sad that .NET and C# are not considered "major I've said it before on here, but the tech community severely underrates .NET today. It's not Windows only (and hasn't been for ~8 years) plus C# is a very nice language. F# is also an option for people who like functional languages. I'd highly recommend giving it a try if you haven't already.

They also severely underrate it's actual usage. For a non "major" language, there sure are a lot of jobs out there.

.NET ain't hip.

Re: HTTP/3 is everywhere but nowhere

#55

Earlier quoted context omitted.

Can .net produce cross platform libraries/executables like Go does? With Go I can develop on Mac and create executables for windows and Linux

Yes, it can. I work on .NET and work on Mac (hate the OS, but the hardware and battery life are way better). Last startup, we shipped AWS t4g Arm64 and GCP x64 Linux containers. A few devs started on Windows (because of their preferred platform), but we all ended up on M1 MacBook Pros using a mix of Rider and VS Code. Common misconception between old .NET Framework and new .NET # (e.g. .NET 9) (MS terrible naming). C…

Are you sure? https://learn.microsoft.com/en-us/dotnet/core/deploying/nati...

"Since there's no standardized way to obtain native macOS SDK for use on Windows/Linux, or Windows SDK for use on Linux/macOS, or a Linux SDK for use on Windows/macOS, Native AOT does not support cross-OS compilation. Cross-OS compilation with Native AOT requires some form of emulation, like a virtual machine or Windows WSL."

Now, you don't have to actually use AOT, the other deployment options are actually much easier to cross-build, but true cross build AOT is still not supported.

(this comment is correct: https://news.ycombinator.com/item?id=43388962 ; runtime-dependent and self-contained are fine)

Re: HTTP/3 is everywhere but nowhere

#56

Earlier quoted context omitted.

> side note: sad that .NET and C# are not considered "major I've said it before on here, but the tech community severely underrates .NET today. It's not Windows only (and hasn't been for ~8 years) plus C# is a very nice language. F# is also an option for people who like functional languages. I'd highly recommend giving it a try if you haven't already.

Can .net produce cross platform libraries/executables like Go does? With Go I can develop on Mac and create executables for windows and Linux

If your code does not rely on native libraries, or you're fine with shipping multiple copies for different operating systems, a single build works everywhere with dotnet installed.

Or you can cross-compile and run without having dotnet on the target system, I do it from Linux to all three platforms all the time, it's pretty seamless. The application can be packaged into a single binary (similar to Go), or as a bunch of files which you can then then package up into a zip file.

Re: HTTP/3 is everywhere but nowhere

#57
My observation is that anything based on public cloud providers using their load balancers is basically using HTTP3 out of the box. This benefits people that use browsers that support this (essentially all browser and mobile browsers). And since it falls back to plain HTTP 1.1, there are no downsides for others.

Sites that use their own apache/nginx/whatever servers are not benefiting from this and need to do work. And this is of course not helped by the fact that http3 support in many servers is indeed still lacking. Which at this point should be a strong hint to maybe start considering something more modern/up to date.

Http clients used for API calls between servers that maybe use pipelining and connection reuse, benefit less from using HTTP3. So, fixing http clients to support http3 is less urgent. Though there probably are some good reasons to support this anyway. Likewise there is little benefit in ensuring communication between microservices in e.g. Kubernetes happens over http3.

Re: HTTP/3 is everywhere but nowhere

#58
it's quite shocking to know that http/3 is still not gain enough opensource libraries support.

Maybe really some users does not care more about it,as a developper I'd rather not taking much overhead to maintain a server that support http/3.

Re: HTTP/3 is everywhere but nowhere

#59

> At the same time, neither QUIC nor HTTP/3 are included in the standard libraries of any major languages including Node.js, Go, Rust, Python or Ruby. .NET actually looking like it has decent support for any teams that are interested[0] (side note: sad that .NET and C# are not considered "major"...). There is an open source C library that they've published that seems rather far along[1] Support for Windows, Linux[2],…

> side note: sad that .NET and C# are not considered "major"... Even Microsoft does not use C# for their new projects. See the new TypeScript compiler that is being rewritten in Go. So I think it is safe to say C# is indeed a minor language.

It's pretty true from recent experience. I've recently started rewriting a C# based desktop/window stream tool because of how weak the support is across the board for C#. Microsoft abandoned WinRTC, Sipsorcery is one guy and is missing VP9 HEVC and AV1 support. And for fancier stuff like using computer shaders for color space conversion, SharpDX is constantly referenced by chatgpt and MS docs, yet it's archived and unmaintained as well. I ended up using media streams VideoFrame class but it and two other classes required to interact with it have unpreventable thread and memory leaks built into the WinRT implementations themselves 4+ years ago. Good times.

All of the above was easy to implement in Rust

Re: HTTP/3 is everywhere but nowhere

#60

Earlier quoted context omitted.

It's horrible that the Internet is slowly becoming a locked-down ecosystem. Everyone should turn off HTTP/3 in protest of this. https://news.ycombinator.com/item?id=43329320

What exactly are sites supposed to do to prevent being the targets of DDoS, spam, fraud, aggressive bots, and other abuse? And it's not "locked down", it's usually just a CAPTCHA as long as you're not coming from an abusive IP range like might happen with a VPN. Also there are a thousand other signals besides HTTP/3. It's not going to make a difference.

The normalization of CAPTCHAs for simply reading what ought to be public information strikes me as very alarming, as does characterizing essential privacy and anti-censorship measures like VPNs as "abusive".

Something like 1% of HTTP hits pose some risk of spam or fraud, those where somebody is trying to post a message or a transaction or something. The other 99% are just requesting a static HTML document or JPEG (or its moral equivalent with unwarranted and untrustworthy dynamic content injected). Static file serving is very difficult to DDoS, even without a caching CDN like Fastly. There is still a potentially large bandwidth cost, but generally the DoS actor has to pay more than the victim website, making it relatively unappealing.

Should web sites really be weighing "a thousand signals" to decide which version of the truth to present a given user with? That sounds dystopian to me.

Post reply on HN