9 ms·

Avoiding HTTP/3 (for a while) as a pragmatic default

92 points by pabs3 4y ago

piperswe 4y ago
Thanks to there always being fallback to older HTTP versions, I've never encountered an issue with HTTP/3 that prevented me from accessing a site. If HTTP/3 doesn't work, then the connection will just end up using HTTP/2 or HTTP/1.1, whichever's available.
- c4mpute 4y ago
  Hopefully, yes. But one can imagine a lot of weird problems with networks treating TCP and UDP differently such that HTTP/3 performance on UDP is degraded with no fallback to earlier TCP based versions happening, because your client will only fall back if there are errors.
- jillesvangurp 4y ago
  I think this article is specifically about running web servers inside of networks with firewalls that block udp on port 443 for whatever reason. There are lots of older networks that have such firewalls and they aren't going to get upgraded overnight. Reaching http3 servers outside those networks is indeed not a problem as the connection gets downgraded appropriately. You'd know this when Google, for example, stops working inside your network as most of their load balancers are serving http3. Users tend to complain about these things and this obviously hasn't been happening. Ergo, connections are being downgraded as you'd expect. But putting up webservers serving http3 in a network that blocks udp3 is indeed not going to work until somebody fixes the firewall. You could still do it and test if browsers from outside the network downgrade correctly. But that seems a bit pointless.
- xyst 4y ago
  Is it possible to catch, from the server side, when this happens? Or is this only a client side event? Would be interesting to see how many will requests get downgraded or not over a long period of time.
klabb3 4y ago
Every time there’s a protocol shift, the stones under which decades of ugly hacks fester are abruptly lifted, exposing them to daylight. On the one hand, those hacks tell stories that are rooted in needs, that should be respected and understood before proceeding. On the other hand, we can’t just give in to “implementation detail squatting” and never evolve our standards. I’d love to have more rigorous analysis of what tricks are pulled, and how those can be addressed from first principles. I’ve yet to see such a take, but that’s understandable, because all this institutional knowledge is spread across segmented information islands.
- NetOpWibby 4y ago
  > On the other hand, we can’t just give in to “implementation detail squatting” and never evolve our standards. I was just lamenting a couple days ago about the email templates written in tables and HTML4 Transitional. It’s 2023, wtf.
  - pas 4y ago
    https://react.email/ https://react.email/ https://demo.react.email/preview/nike-receipt https://demo.react.email/preview/nike-receipt doesn't seem that bad
    - NetOpWibby 4y ago
      But it is: https://demo.react.email/preview/nike-receipt?view=source&lang=markup https://demo.react.email/preview/nike-receipt?view=source&la... Inline styling and tables, instead of semantic HTML5 and a style block.
mgaunard 4y ago
HTTP/2 is just plain silly, HTTP/3 is a silly idea but implemented correctly. Neither are particularly useful unless you're a web browser. I'm sticking to HTTP/1.1 myself in all of my code.
- jFriedensreich 4y ago
  comments like this without giving arguments why something is silly are not super helpful
  - mgaunard 4y ago
    You'd simply need to know what those protocols are and how TCP works to understand the argument. Funnily enough most engineers don't seem to have any idea how TCP works these days.
    - ilyt 4y ago
      That is an example of argument: > HTTP/2 is bad because XYZ, HTTP 3 at least fixes Z Note giving reasons, and preferably also reasoning behind those reasons. You know, the "arguments" Here is what clown riding that dunning-kruger peak thinks that "argument" is: > HTTP/2 is just plain silly, HTTP/3 is a silly idea but implemented correctly.
    - mort96 4y ago
      You provided no argument, there is nothing to understand.
- tlamponi 4y ago
  At Proxmox we use HTTP/2 (h2) in our backup project to asynchronously stream chunked data to the server, works great for that and wouldn't be really possible with HTTP 1.1; at least not with major headache and extra overhead. We also plan to closer evaluate HTTP/3 (h3) soon, mainly to see how the promised improvements, like no head of line blocking, turn out in practice for our use case. So I'd disagree that h2 or h3 is useless "unless you're a web browser"; but sure if you use HTTP only to provide a simple text (e.g., JSON) based API it might not be _that_ relevant. But some benefits like faster TLS setup might even make a difference there, e.g., faster initial startup, fewer packets transmitted, IIRC even packet sniffing should be a bit harder to do with h3. If those benefits are worth it on its own, depends then probably on how easy it's to integrate in your project, iow., if your framework/standard lib/ecosystem/... already supports h3 nicely. We use the rust hyper crate for most of our HTTP* communication, and their h3 implementation is still marked as experimental; and as we're not in a rush we'll just wait until the hyper project stabilizes h3.
tsujamin 4y ago
probably not it’s usecase, but as a pentester HTTP/3 libraries are a great way to turn unreliable datagram style c2 (udp etc) into a dumb reliable stream for 0 effort ;) Shame about the minimum MTU otherwise it’d be perfect
- easrng 4y ago
  Why not stcp like webrtc does (iirc)?
  - remram 4y ago
    SCTP?
    - easrng 4y ago
      oops yeah, typo :facepalm:
withinboredom 4y ago
I'm still waiting for proper support in networking infrastructure (like Direct Server Return), firewalls, and load balancers.
charcircuit 4y ago
HTTP/3 is already widely deployed and most clients use TCP fallback which allows people with an incompatible network to fallback to using an older HTTP version. >since HTTP/3 is the newer and less common version, it's the version most likely to not work. Which means those clients will end up using HTTP/2. >I'm also uncertain about how much HTTP/3 usage there is among the big players like Google, Cloudflare, and so on Google and Cloudflare have had it for years. Other big players have adopted it too.
rfmoz 4y ago
Looking outside “desktop” environments the state is still a mess. There are api services using libraries capables of connecting via HTTP/3 but hanging under firewalls or network security appliances that hit that UDP traffic in weird ways. From the outside, you can only expect the complaint from the customer.
- rfmoz 4y ago
  As note, for client browsers, there is a way to know their network problems. It's called "NEL" https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/NEL https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/NE... An interesting usage from Wikimedia: https://www.usenix.org/sites/default/files/conference/protected-files/sre23amer_slides_danis_v2.pdf https://www.usenix.org/sites/default/files/conference/protec...
francislavoie 4y ago
Just a reminder, Caddy supports and enables HTTP/3 by default as of v2.6.0 (from ~September).
- NetOpWibby 4y ago
  Sweet, my decision to switch from nginx to Caddy continues to be a great one.
- xiphias2 4y ago
  It's strange that I had to set up Caddy as a proxy just to connect to a nodejs http server, because setting up Caddy was so much easier than setting up https in nodejs. But at least it just works for everything I have thrown to it.
  - maccard 4y ago
    That's because node and friends are commonly deployed with tls termination at a load balancer level, and that you likely want a faster server serving up static content (Apache/nginx/caddy/whatever). Given the choice between encouraging people to shoddily wire up TLS in their apps, and providing plug and play support in things like Caddy, I prefer the latter any day of the week!
    - xiphias2 4y ago
      I don't understand what ,,shoddily wire up'' means. I had to create, maintain and monitor a new service that just to add encryption to my simple web server (actually just to be able to connect to my web server from my browser), that should just be a simple function call. If everything would be implemented like this, next time leftpad should be a web service on my machine as well?
- mastax 4y ago
  Ah yes, that update broke one of our applications. I've been meaning to try the update again with HTTP3 disabled but haven't had the time.
neonsunset 4y ago
It is a must to break existing networking so that TCP bias goes away. It is a big shame only TCP and mostly UDP work while every other protocol is filtered. IP was not designed this way. Therefore, to reduce pain, it should be inflicted often. Especially in mobile setups, which are the primary target of QUIC with resumable sessions.
- gsich 4y ago
  What? Nearly everything works, port 25 might not, depending on ISP. You can also use other stuff like SCTP if you have services using it. Corporate networks are not the Internet.
miyuru 4y ago
It's sad to see these kinds of posts from universities who were connected to the internet early on. (the blog is hosted on AS239) This blog post itself served from HTTP/1.1 and IPv4 for me. I guess the improving internet is handed over to the big companies who benefit them.
- j16sdiz 4y ago
  Benefit them, not us. They have no incentive to hold backward compatibility and putting smaller websites offline
- superkuh 4y ago
  I strongly disagree. HTTP/3 was a google's protocol and they and microsoft used their employees on the IETF to open-wash it. It is designed exclusively for the use cases of corporations and institutions to the detriment to the use cases of human persons. For example, you will not find any implementation of HTTP/3 that allows you to connect to another computer without that computer first getting continual approval from a third party corporation or institution. That is, you can't just connect to a friend's HTTP/3 web server, or your own HTTP/3 server on your LAN with any browser (or otherwise HTTP/3 client) out there. First you have to ask, say, LetsEncrypt for permission. HTTP/3 is not for human people. It's for corporate people and it will serve them well. But please don't mistake not using HTTP/2 or HTTP/3 with their corporate crap as being backwards. It's the the other way around. I'll be sad when the web dies and all we're left with is Google's centrally controlled QUIC.
  - jeroenhd 4y ago
    Are you saying self signed certificates and custom certificate authorities are banned in HTTP/3? Because as far as I know, there's absolutely nothing stopping you from setting up your own crypto if you don't like certificate authorities.
    - superkuh 4y ago
      All current HTTP/3 implementations will not let you use a self-signed cert. Without the CA root it will not connect. The spec for HTTP/3 says this should be the default. There are compile-time flags you can use to enable it but with Google/Microsoft/Apple browsers all not, good luck being able to have people connect to your site. I'm saying that there is no way for me to distribute and install my custom CA into the browsers of every random person around the globe that will try to visit my website on software defined radio. I've self-signed my website(s) for 20 years now. In the past it did not matter. But over the last few years I've noticed that actual browser connections are disappearing and all that's left is http bots. They're the only HTTP clients not failing to load my page because of $browsers HTTPS only configuration causing them to see my self-signed cert and thus the browser scaremongering about it causing them to close the tab. HTTP/1.1 going away will be the death of the personal website.
egberts1 4y ago
Yep, avoid HTTTP/3 until Google fixes Chrome to be able to do TLS-negotiate only for a ChaCha encryption algorithm and only in HTTP/2. Your basic test case of a web browser being able to do ChaCha-HTTP/2-only is simply to visit https://egbert.net/ https://egbert.net/ and successfully get a web page.
shpx 4y ago
Only bad or new software developers update software. Pin your dependencies, don't use new protocols, Snow Leopard was the last good macOS version. Library doesn't work on the newest Node or Python version? Who cares, it's only been out for half a year who's even using it yet? Some people spent hundreds of hours making something better, why would you want to use the result?
- loo 4y ago
  > Some people spent hundreds of hours making something better, why would you want to use the result?
jeroenhd 4y ago
This university seems to be the exact reason why network protocols are stuck in their terrible 80s designs. They've set up an incredibly restrictive systems of firewalls and networks, making it super hard for themselves to upgrade their own network or adapt to the world around them. Then they write a big post about how much work allowing UDP/443 through their network supposedly is, proving that they not only already blocked tons of legitimate traffic (OpenVPN over 443 is super common) but also that apparently their setup is set up in a way that's impossible for them to manage. They're running some kind of firewall system that's analysing people's traffic and they're afraid HTTP/3 will put a stop to that. That means either their tooling isn't maintained well enough or they employ some kind of sketchy trickery to get the older protocols to play "nice" with their data collection. They implore others to please stick to the protocols of the past so they don't need to change their network in the future. This university acts like the worst ISP imaginable. Who even uses a whitelist for outgoing ports anymore? Block whatever stupid protocols Windows uses for file sharing so you don't leak your credentials, that's all the outgoing filtering you need. If I were a student or an employee there, I would make sure that every single but leaving my devices is going through some kind of encrypted VPN, though I'm sure they'll try their hardest to block that too. Universities are research facilities, they're supposed to be at the forefront of technology, not run into service issues because their policies are frozen in the late 90s. When HTTP/3 hits the common software packages, I'll be turning it on on all of my services purely out of spite against institutions and companies like this. If your network can't deal with industry standards, it deserves all the shame and support tickets it'll generate.
- nixgeek 4y ago
  Wow, I took away completely different things from this article than you.
- jefftk 4y ago
  I think you're confused about the context in which they are not yet supporting HTTP/3: they are deciding to hold off on serving it, not on allowing it to pass through their network: All of this is of course academic until Ubuntu's version of Apache supports HTTP/3. We're quite unlikely to switch web servers to get HTTP/3 They're worried some of their users will be in environments that don't properly support QUIC, and if they started serving HTTP/3 today they might have more support hassle.
eNV25 4y ago
This reminds me of secondary school, where the IT guy blocked UDP completely. WireGuard didn't work, HTTP3/QUIC didn't work, network time didn't work, and probably a bunch of other stuff.
- ocdtrekkie 4y ago
  This is perfectly reasonable if you provide internal network time, and you don't want people using your network for illegal activity. At work we don't block "all UDP", but we block anything QUIC, anything classified as a VPN or proxy, and anything like DoH which is intended to obscure visibility into network usage. Organizations who are not doing this are not adequately managing their network.
  - srj 4y ago
    Isn't it kind of creepy that you manage which websites people can visit and spy on their usage? I disagree that this is needed for "adequately managing their network."
    - throwawaymaths 4y ago
      Maybe if you're an ISP. If you're a uni, a govt agency, a workplace, maybe not.
    - ocdtrekkie 4y ago
      Generally we don't monitor activity, we just filter it. As I say "I'm an engineer, not the HR department". But there's significant legal and reputational risk to not preventing illegal activity from your network, and major security risks to not blocking malicious content from things like ad companies. Unsurprisingly, the lead pusher of HTTP/3 and QUIC is the world's most pervasive ad company.
  - yencabulator 4y ago
    What's the point of blocking QUIC but not TCP port 443?
Joeyda3rd2 4y ago
ELI5: Why is QUIC better over TCP?

92 points by pabs3 4y ago

Thanks to there always being fallback to older HTTP versions, I've never encountered an issue with HTTP/3 that prevented me from accessing a site. If HTTP/3 doesn't work, then the connection will just end up using HTTP/2 or HTTP/1.1, whichever's available.

c4mpute 4y ago
Hopefully, yes. But one can imagine a lot of weird problems with networks treating TCP and UDP differently such that HTTP/3 performance on UDP is degraded with no fallback to earlier TCP based versions happening, because your client will only fall back if there are errors.
jillesvangurp 4y ago
I think this article is specifically about running web servers inside of networks with firewalls that block udp on port 443 for whatever reason. There are lots of older networks that have such firewalls and they aren't going to get upgraded overnight. Reaching http3 servers outside those networks is indeed not a problem as the connection gets downgraded appropriately. You'd know this when Google, for example, stops working inside your network as most of their load balancers are serving http3. Users tend to complain about these things and this obviously hasn't been happening. Ergo, connections are being downgraded as you'd expect. But putting up webservers serving http3 in a network that blocks udp3 is indeed not going to work until somebody fixes the firewall. You could still do it and test if browsers from outside the network downgrade correctly. But that seems a bit pointless.
xyst 4y ago
Is it possible to catch, from the server side, when this happens? Or is this only a client side event? Would be interesting to see how many will requests get downgraded or not over a long period of time.

klabb3 4y ago

Every time there’s a protocol shift, the stones under which decades of ugly hacks fester are abruptly lifted, exposing them to daylight. On the one hand, those hacks tell stories that are rooted in needs, that should be respected and understood before proceeding. On the other hand, we can’t just give in to “implementation detail squatting” and never evolve our standards. I’d love to have more rigorous analysis of what tricks are pulled, and how those can be addressed from first principles. I’ve yet to see such a take, but that’s understandable, because all this institutional knowledge is spread across segmented information islands.

NetOpWibby 4y ago
> On the other hand, we can’t just give in to “implementation detail squatting” and never evolve our standards. I was just lamenting a couple days ago about the email templates written in tables and HTML4 Transitional. It’s 2023, wtf.
- pas 4y ago
  https://react.email/ https://react.email/ https://demo.react.email/preview/nike-receipt https://demo.react.email/preview/nike-receipt doesn't seem that bad
  - NetOpWibby 4y ago
    But it is: https://demo.react.email/preview/nike-receipt?view=source&lang=markup https://demo.react.email/preview/nike-receipt?view=source&la... Inline styling and tables, instead of semantic HTML5 and a style block.

mgaunard 4y ago

HTTP/2 is just plain silly, HTTP/3 is a silly idea but implemented correctly. Neither are particularly useful unless you're a web browser. I'm sticking to HTTP/1.1 myself in all of my code.

jFriedensreich 4y ago
comments like this without giving arguments why something is silly are not super helpful
- mgaunard 4y ago
  You'd simply need to know what those protocols are and how TCP works to understand the argument. Funnily enough most engineers don't seem to have any idea how TCP works these days.
  - ilyt 4y ago
    That is an example of argument: > HTTP/2 is bad because XYZ, HTTP 3 at least fixes Z Note giving reasons, and preferably also reasoning behind those reasons. You know, the "arguments" Here is what clown riding that dunning-kruger peak thinks that "argument" is: > HTTP/2 is just plain silly, HTTP/3 is a silly idea but implemented correctly.
  - mort96 4y ago
    You provided no argument, there is nothing to understand.
tlamponi 4y ago
At Proxmox we use HTTP/2 (h2) in our backup project to asynchronously stream chunked data to the server, works great for that and wouldn't be really possible with HTTP 1.1; at least not with major headache and extra overhead. We also plan to closer evaluate HTTP/3 (h3) soon, mainly to see how the promised improvements, like no head of line blocking, turn out in practice for our use case. So I'd disagree that h2 or h3 is useless "unless you're a web browser"; but sure if you use HTTP only to provide a simple text (e.g., JSON) based API it might not be _that_ relevant. But some benefits like faster TLS setup might even make a difference there, e.g., faster initial startup, fewer packets transmitted, IIRC even packet sniffing should be a bit harder to do with h3. If those benefits are worth it on its own, depends then probably on how easy it's to integrate in your project, iow., if your framework/standard lib/ecosystem/... already supports h3 nicely. We use the rust hyper crate for most of our HTTP* communication, and their h3 implementation is still marked as experimental; and as we're not in a rush we'll just wait until the hyper project stabilizes h3.

tsujamin 4y ago

probably not it’s usecase, but as a pentester HTTP/3 libraries are a great way to turn unreliable datagram style c2 (udp etc) into a dumb reliable stream for 0 effort ;) Shame about the minimum MTU otherwise it’d be perfect

easrng 4y ago
Why not stcp like webrtc does (iirc)?
- remram 4y ago
  SCTP?
  - easrng 4y ago
    oops yeah, typo :facepalm:

withinboredom 4y ago

I'm still waiting for proper support in networking infrastructure (like Direct Server Return), firewalls, and load balancers.

charcircuit 4y ago

HTTP/3 is already widely deployed and most clients use TCP fallback which allows people with an incompatible network to fallback to using an older HTTP version. >since HTTP/3 is the newer and less common version, it's the version most likely to not work. Which means those clients will end up using HTTP/2. >I'm also uncertain about how much HTTP/3 usage there is among the big players like Google, Cloudflare, and so on Google and Cloudflare have had it for years. Other big players have adopted it too.

rfmoz 4y ago

Looking outside “desktop” environments the state is still a mess. There are api services using libraries capables of connecting via HTTP/3 but hanging under firewalls or network security appliances that hit that UDP traffic in weird ways. From the outside, you can only expect the complaint from the customer.

rfmoz 4y ago
As note, for client browsers, there is a way to know their network problems. It's called "NEL" https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/NEL https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/NE... An interesting usage from Wikimedia: https://www.usenix.org/sites/default/files/conference/protected-files/sre23amer_slides_danis_v2.pdf https://www.usenix.org/sites/default/files/conference/protec...

francislavoie 4y ago

Just a reminder, Caddy supports and enables HTTP/3 by default as of v2.6.0 (from ~September).

NetOpWibby 4y ago
Sweet, my decision to switch from nginx to Caddy continues to be a great one.
xiphias2 4y ago
It's strange that I had to set up Caddy as a proxy just to connect to a nodejs http server, because setting up Caddy was so much easier than setting up https in nodejs. But at least it just works for everything I have thrown to it.
- maccard 4y ago
  That's because node and friends are commonly deployed with tls termination at a load balancer level, and that you likely want a faster server serving up static content (Apache/nginx/caddy/whatever). Given the choice between encouraging people to shoddily wire up TLS in their apps, and providing plug and play support in things like Caddy, I prefer the latter any day of the week!
  - xiphias2 4y ago
    I don't understand what ,,shoddily wire up'' means. I had to create, maintain and monitor a new service that just to add encryption to my simple web server (actually just to be able to connect to my web server from my browser), that should just be a simple function call. If everything would be implemented like this, next time leftpad should be a web service on my machine as well?
mastax 4y ago
Ah yes, that update broke one of our applications. I've been meaning to try the update again with HTTP3 disabled but haven't had the time.

neonsunset 4y ago

It is a must to break existing networking so that TCP bias goes away. It is a big shame only TCP and mostly UDP work while every other protocol is filtered. IP was not designed this way. Therefore, to reduce pain, it should be inflicted often. Especially in mobile setups, which are the primary target of QUIC with resumable sessions.

gsich 4y ago
What? Nearly everything works, port 25 might not, depending on ISP. You can also use other stuff like SCTP if you have services using it. Corporate networks are not the Internet.

miyuru 4y ago

It's sad to see these kinds of posts from universities who were connected to the internet early on. (the blog is hosted on AS239) This blog post itself served from HTTP/1.1 and IPv4 for me. I guess the improving internet is handed over to the big companies who benefit them.

j16sdiz 4y ago
Benefit them, not us. They have no incentive to hold backward compatibility and putting smaller websites offline
superkuh 4y ago
I strongly disagree. HTTP/3 was a google's protocol and they and microsoft used their employees on the IETF to open-wash it. It is designed exclusively for the use cases of corporations and institutions to the detriment to the use cases of human persons. For example, you will not find any implementation of HTTP/3 that allows you to connect to another computer without that computer first getting continual approval from a third party corporation or institution. That is, you can't just connect to a friend's HTTP/3 web server, or your own HTTP/3 server on your LAN with any browser (or otherwise HTTP/3 client) out there. First you have to ask, say, LetsEncrypt for permission. HTTP/3 is not for human people. It's for corporate people and it will serve them well. But please don't mistake not using HTTP/2 or HTTP/3 with their corporate crap as being backwards. It's the the other way around. I'll be sad when the web dies and all we're left with is Google's centrally controlled QUIC.
- jeroenhd 4y ago
  Are you saying self signed certificates and custom certificate authorities are banned in HTTP/3? Because as far as I know, there's absolutely nothing stopping you from setting up your own crypto if you don't like certificate authorities.
  - superkuh 4y ago
    All current HTTP/3 implementations will not let you use a self-signed cert. Without the CA root it will not connect. The spec for HTTP/3 says this should be the default. There are compile-time flags you can use to enable it but with Google/Microsoft/Apple browsers all not, good luck being able to have people connect to your site. I'm saying that there is no way for me to distribute and install my custom CA into the browsers of every random person around the globe that will try to visit my website on software defined radio. I've self-signed my website(s) for 20 years now. In the past it did not matter. But over the last few years I've noticed that actual browser connections are disappearing and all that's left is http bots. They're the only HTTP clients not failing to load my page because of $browsers HTTPS only configuration causing them to see my self-signed cert and thus the browser scaremongering about it causing them to close the tab. HTTP/1.1 going away will be the death of the personal website.

egberts1 4y ago

Yep, avoid HTTTP/3 until Google fixes Chrome to be able to do TLS-negotiate only for a ChaCha encryption algorithm and only in HTTP/2. Your basic test case of a web browser being able to do ChaCha-HTTP/2-only is simply to visit https://egbert.net/ https://egbert.net/ and successfully get a web page.

shpx 4y ago

Only bad or new software developers update software. Pin your dependencies, don't use new protocols, Snow Leopard was the last good macOS version. Library doesn't work on the newest Node or Python version? Who cares, it's only been out for half a year who's even using it yet? Some people spent hundreds of hours making something better, why would you want to use the result?

loo 4y ago
> Some people spent hundreds of hours making something better, why would you want to use the result?

jeroenhd 4y ago

This university seems to be the exact reason why network protocols are stuck in their terrible 80s designs. They've set up an incredibly restrictive systems of firewalls and networks, making it super hard for themselves to upgrade their own network or adapt to the world around them. Then they write a big post about how much work allowing UDP/443 through their network supposedly is, proving that they not only already blocked tons of legitimate traffic (OpenVPN over 443 is super common) but also that apparently their setup is set up in a way that's impossible for them to manage. They're running some kind of firewall system that's analysing people's traffic and they're afraid HTTP/3 will put a stop to that. That means either their tooling isn't maintained well enough or they employ some kind of sketchy trickery to get the older protocols to play "nice" with their data collection. They implore others to please stick to the protocols of the past so they don't need to change their network in the future. This university acts like the worst ISP imaginable. Who even uses a whitelist for outgoing ports anymore? Block whatever stupid protocols Windows uses for file sharing so you don't leak your credentials, that's all the outgoing filtering you need. If I were a student or an employee there, I would make sure that every single but leaving my devices is going through some kind of encrypted VPN, though I'm sure they'll try their hardest to block that too. Universities are research facilities, they're supposed to be at the forefront of technology, not run into service issues because their policies are frozen in the late 90s. When HTTP/3 hits the common software packages, I'll be turning it on on all of my services purely out of spite against institutions and companies like this. If your network can't deal with industry standards, it deserves all the shame and support tickets it'll generate.

nixgeek 4y ago
Wow, I took away completely different things from this article than you.
jefftk 4y ago
I think you're confused about the context in which they are not yet supporting HTTP/3: they are deciding to hold off on serving it, not on allowing it to pass through their network: All of this is of course academic until Ubuntu's version of Apache supports HTTP/3. We're quite unlikely to switch web servers to get HTTP/3 They're worried some of their users will be in environments that don't properly support QUIC, and if they started serving HTTP/3 today they might have more support hassle.

eNV25 4y ago

This reminds me of secondary school, where the IT guy blocked UDP completely. WireGuard didn't work, HTTP3/QUIC didn't work, network time didn't work, and probably a bunch of other stuff.

ocdtrekkie 4y ago
This is perfectly reasonable if you provide internal network time, and you don't want people using your network for illegal activity. At work we don't block "all UDP", but we block anything QUIC, anything classified as a VPN or proxy, and anything like DoH which is intended to obscure visibility into network usage. Organizations who are not doing this are not adequately managing their network.
- srj 4y ago
  Isn't it kind of creepy that you manage which websites people can visit and spy on their usage? I disagree that this is needed for "adequately managing their network."
  - throwawaymaths 4y ago
    Maybe if you're an ISP. If you're a uni, a govt agency, a workplace, maybe not.
  - ocdtrekkie 4y ago
    Generally we don't monitor activity, we just filter it. As I say "I'm an engineer, not the HR department". But there's significant legal and reputational risk to not preventing illegal activity from your network, and major security risks to not blocking malicious content from things like ad companies. Unsurprisingly, the lead pusher of HTTP/3 and QUIC is the world's most pervasive ad company.
- yencabulator 4y ago
  What's the point of blocking QUIC but not TCP port 443?

Joeyda3rd2 4y ago

ELI5: Why is QUIC better over TCP?