My feeling (and why I wrote the article) is that it's easy to overlook that you need to do something active to enable your users to use HTTP/3. Previous upgrades to HTTPS of various forms generally required no firewall changes, unless you had a broken firewall that insisted on seeing specific things in TLS handshakes and dropped the connection otherwise. For instance, you can add HTTP/2 to your own servers or talk to HTTP/2 servers outside with no firewall change. But any shift to (or toward) HTTP/3 now requires firewall changes unless you're already passing UDP 443. You can't just deploy it on your own servers or assume that your users will be able to transparently take advantage of it; now you may need to do something active to enable it. It's easy to overlook that, especially since we're not likely to see active failures when HTTP/3 doesn't work, just a quietly degraded experience.

(I'm the author of the linked-to entry, and I should have done a better job of explaining this in the original entry.)

> you need to do something active to enable your users to use HTTP/3

Another way of looking at it would be that you have been actively blocking HTTP/3 (and probably many other useful but uncommon protocols) for your users and all that needs to happen to make it work is for you to stop doing that. Blocking all unknown things by default is just another form of protocol ossification.

That said when you're responsible for network security I can imagine how a block-by-default policy is tempting and hopefully people subjecting their users to such a policy will read your article and add an exception.

As pointed out elsewhere in thread, if your users are untrusted and not under your direct administrative control (e.g. students in a dorm, hotel guests, et c) then default-allow-everything jeopardizes your upstream transit connection (e.g. if they start spamming).

You owe it to others on the internet to not allow everything out indiscriminately from untrusted strangers who happen to be on your access network. It’s just neighborly to make sure you’re not sending ddos or spam, for example.

> if your users are untrusted and not under your direct administrative control (e.g. students in a dorm, hotel guests, et c) then default-allow-everything jeopardizes your upstream transit connection (e.g. if they start spamming).

How is that different from an ISP? Or do you think ISPs should also block everything except TCP ports 80 and 443?

ISPs throttle and block lots of things. Many residential ISPs block port 25, for example.

Some people get it into their heads that just because their code works right now that it is somehow "done" and will never need maintenance, so they don't budget for any maintenance work or knowledge upkeep. Then when the world inevitably changes around the program, some of the initial assumptions are no longer valid and (possibly extensive) changes are required but no resources available to enact them. The only cheap solution available is to complain about the changes in the world and try to get them rolled back.

I feel like blaming developers (or management) for this is just fighting human nature which never ends well. Rather we should look at deeper root causes, like why these initial assumptions keep changing, and why there is so much churn in some ecosystems.

If the incentives aren’t there to do proper maintenance, no amount of blaming people for following those incentives will fix the problem.

I don't mean to blame anyone here, it is like you say: just human nature. The same is true about initial assumptions and software ecosystems btw, change has been their nature since basically forever and calling that a "root cause" seems like being angry at a thistle for having thorns. The world/human society has never been static, why should software be an exception to this?

In any case it does not really matter; either Utoronto will eventually rewrite their firewall configs, or they won't and then they will not be able to use HTTP3. These issues have a way of eventually becoming urgent enough to fix and at that time the incentives will sort themselves out.

> I don't really understand what the fuss is about.

There are only so many hours in the day/week, and it's usually already filled with work that needs to be done for internal needs. Someone external comes along unbidden and wants to add to your work for something that seems to have very little benefit for the organization.

Why should I do the work for them? What problem of mine does this effort solve?

“Just deal with it” is problematic for adoption. Python being an excellent example, looking at Python 2.7. IPv6 being another one.

If firewall changes are necessary for HTTP/3 to be adopted (eg connection tracking in routers may not work anymore), that can cause big problems in adoption.

I don't think you can compare it to IPv6. IPv6 requires explicit adoption on the network side. In the case of HTTP/3, the vast majority of clients are already able to use it perfectly fine. They won't have any network firewalls in place that block UDP port 443. There are (virtually) no consumer ISPs that do that.

> If firewall changes are necessary for HTTP/3 to be adopted (eg connection tracking in routers may not work anymore), that can cause big problems in adoption.

If firewall changes are necessary for HTTP/3, then it's a slightly 'dumb' protocol in some ways.

If that's a prerequisite, then perhaps more effort should have been spent in getting SCTP and DCCP accepted and run HTTP over one/both of those. QUIC seems to have basically the same feature set AFAICT.

Besides the architecture decision of having QUIC being on top of UDP, are there specific features that are much better than SCTP and/or DCCP? Are the other two better in particular areas? How complementary or competitive are the two approaches? (Genuinely curious.)

The point you are trying to make is that people are irrational, therefore:

Even if the effort required to adopt something would bring in disproportionate returns, they would skip it because the effort is nonzero?

(just a generalization, no idea if H3 worth it or not)

The effort required may be less than the benefit as a whole, but as an individual probably not.

Moving from Python 2.7 to 3 involves a lot of work for some people with an old stable code base, and benefits those writing new code.

Of course as Python is open there’s nothing stoping you from maintaining 2.7 yourself - except that’s more work, and until now you’ve likely benefitted from the work others have done more than you’ve contributed.

I had some fairly new code written in nodejs recently that fubared when node was upgraded. Looking at the tangled web of code to try to get working again, and the fact it was under 13 months old before it was reduced to a valueless mess, I spent 4 hours replacing its function with a stable language as that was a better use of my time.

Firewall changes are only needed if your firewall rules were unreasonable to begin with.

> connection tracking in routers may not work anymore

What do you mean by this? Tracking of UDP flows has been supported by routers for decades.