The Long Road to HTTP/3 | Hacker News Reader

The Long Road to HTTP/3

scorpil.com

90 pointstodsacerdoti77 comments

Http 1.1 is still awesome. Even with all the incoming changes on front-end like js modules and all that, it feels a great fit that is also simple and reliable. Not only that but in a way http 1.1 makes http 2.0 look like the typical over-engineering approach to a non-existing problem, for the most part.

The problem doesn't exist for you.

But plenty of people have high latency internet connections.

Either due to technology (Mobile network, satellite) or due to them being very far from internet exchanges and the server's they want to connect to.

Here is an example of the speed advantage on a low latency connection:

https://youtu.be/QCEid2WCszM

Of course with my 1gbps broadband in a capital city both are pretty much instant when doing the test: https://imagekit.io/demo/http2-vs-http1

But that's not the majority, it's not most cases. Especially if you leave a city and are on mobile internet with poor signal.

That example seems to be arbitrarily constructed to benefit from parallel connections and does not reflect typical HTTP transfer payloads.

In reality, Google mostly failed to show scientific proof that HTTP/2.0 provides beneficial on typical connections - one major reasoning why even introducing QUIC in HTTP/3. A lot of "amateur benchmarks" float the net claiming HTTP/2 speed superiority, but often the measurements are flawed (not taking TCP peculiarity like congestion control into account or even including it in the analysis; classic fault is failure to disable TCP initcwnd caching or flushing the cache when doing benchmarks).

Anecdotal, but I've encountered so many legacy HTTP/1 applications on typical corporate VPN networks where the latency was horrible (due to the VPN and also due to the backend responses adding even more latency). What I've done in some cases is just thrown an HTTP/2 proxy in front of these and saw an immediate and very user-perceptible performance improvement for the user. So much so that people kept asking why using the proxied version I stood up was so much faster than going directly to the origin server.

This is actually quite a good example that websites are bloated and this problem is tried to be solved or worked-around at the protocol level. Which is adding even more bloat and craft in terms of code complexity.

These are the two sides of complexity: It can create marvelous web applications and it can create no visible advantage.

Yes, some websites are certainly bloated and for those it is simply a band-aid. But other websites really do make dozens of requests and there is no way to bundle or reduce these. Just think about a photo-sharing website or forum which loads thumbnails or user avatars for dozens of users in a discussion. This is not something that you can sprite together.

Sure you can. Even without javascript. If you really wanted to, you could even make it work in IE 5, in a single request (I think).

I we're discussing whether is reasonable - 9/10 slow pages I have encountered are slow because of "content" they push on you and would add even more garbage if they could get away with it. Of the rest - most were the opposite of engineered. Tiny minority that can't be bothered to optimize - I don't mind.

You mention sites with sprites, but I would really like to see an example of a sites that are slow on HTTP<2 for good reasons, i.e. not 90% of data being ads, trackers, popups, auto-playing videos and generating content via multi-MB javascript libraries, because that's how it's done these days.

It is a bit over the top, but the patterns are still indicative of the naive approaches you'd typically start out with.

Yes, there are hacks to work around it (bundling and spritesheets), but they have other tradeoffs, like losing ~all of your cache granularity.

I've seen a lot of compromises around REST because of http 1.1 overhead.

A great example of this happens when someone wants to query for a list of resources.

The rest way for this would be to do requests like this

    get /foo/1
    get /foo/2
    get /foo/3

However, unless you spin up a bunch of parallel connections (wasting a bunch of resources both in the servers and the client), you are going to experience performance issues.

The compromise is to create endpoints that look like this

    post /foo [1,2,3]

That saves the connection problem but creates a bunch of new issues. The client can send arbitrary request sizes to single servers (making LBing more difficult). It's not idiomatic, which means things like Http caching simply can't be used (or at least are less effective). A lot of http clients will do auto-retry but only for idempotent verbs, that's gone, you now need to implement all that stuff yourself.

http2 fixes all that. Making parallel requests for n datapoints isn't nearly as big an issue. Those requests can be fanned out to a bunch of servers and those servers can be in charge of figuring how how much batching thing should be doing before reaching out to the DB. Making it impossible for a single client to really tank the system.

Certainly you can work around this, usually by having the service farm out work over a message bus so you don't run into the problem of a single server going down due to a big request. However, the reason those message buses work and are fast is precisely because they are similar to Http2.

All of these have major consequences for backend services. If I have a fleet of apps talking to another fleet of apps, then it matters, a LOT, if each of those apps are creating 20 TCP connections to the other fleet. Get the wrong kind of load storm and your backend will topple over.

Now, is this super scientific? No. Rather it's based on what I've seen in the field.

Http2 has a ton of benefits when doing a lot of small message communication.

I never followed it that closely, but from afar HTTP/2 always seemed like an amazingly stupid idea to me, and I always wondered if I was missing something -- apart from all the bloat and complexity, multiplexing several streams over TCP is a typical networking rookie mistake, because chances are you will be caught out by head-of-line blocking.

First there was all this hype how awesome HTTP2 would be, no mention of head of line blocking. Then, several years later, lo and behold HTTP3 is hyped next, and one big motivation is that HTTP2 turned out to have a head of line blocking problem.

What on earth is going on here? Google obviously has great engineering talent and HTTP2 must have been high profile enough to not leave to a bunch of interns. So there must be more nuance to this, does anyone know the score?

As explained in the article, HTTP/2 solves a HTTP-level head-of-line blocking issue over HTTP/1.1, but retains TCP-level head-of-line blocking, which is later solved by HTTP/3.

The alternative to TCP head-of-line blocking is either using a separate connection per request (which was the original performance bottleneck) or using UDP (which would've been a rather big change coming from HTTP/1.1).

Now these problems are solved incrementally, and HTTP/2 plays a part in that. Which part is stupid?

I might be wrong, but is there real evidence that HTTP/2 "solves" the HTTP head of line blocking issue, in a disease was worse than the cure sort of way? Of course the reason people try to multiplex higher level protocol streams over TCP is some butt-hurt over cost/availability of multiple TCP connections and a desire to make the higher level protocol appear to have more "parallelism" than is really there. In the case of HTTP so that e.g. you are not forced to use sprite-sheets, data-urls, or just less bloat in order to minimize load latency.

My experience so far is that in practice this rarely works out, you end up with nastier TCP level issues instead and I get the impression that this has been the actual experience with HTTP/2 as well.

In that case the stupid part would be assuming that multiplexing over TCP is a good idea, despite various cautionary tales to the contrary.

As I said, I haven't looked into this carefully so my superficial impressions might well be wrong, which is why I'd appreciate input from someone who has properly looked into it.

> The alternative to TCP head-of-line blocking is either using a separate connection per request (which was the original performance bottleneck) or using UDP (which would've been a rather big change coming from HTTP/1.1).

And of course SCTP (nor DCCP) are usable on the general Internet.

I sometimes idly wonder if one of the last favors Google and the other IT behemoths could do the open web before being broken up is just announcing a plan to just use SCTP for Important Thing, and fuck people who are sitting behind broken middleware and if they don't like it complain to the idiots who block SCTP upstream (mutatis mutandis for a zillion other things that are only there to work around broken middleware).

Of course there is zero chance of this happening (for one thing, it would probably greatly increase the chances of getting broken up earlier rather than later), but it's kind of nice to imagine someone of sufficient size throwing their weight around to stop socializing costs and shake up the useable protocol stack a bit again, and retire a lot of horrible hacks and complexity in one fell swoop.

I'd be happy with firewall makers, instead of having "tcp" or "udp" for the protocol, have (e.g.) "stream" or "dgram". One can then have both "tcp" and "sctp" with-in "stream" and the rules wouldn't have to have special cases. DCCP would be with-in "dgram".

> But plenty of people have high latency internet connections.

The problem with HTTP 2.0 is it does not really improve the performance in real life as in Google's "real life benchmarks," it especially does not improve the situation on lossy, and throttled connections, and may actually lead to a degradation over HTTP 1.1.

The "real life benchmarks" data from Google about QUIC is put under doubt in this light.

HTTP/2 seems to be a fairly typical instance of second-system syndrome, with HTTP/3 being the engineers doubling down.

I wish Google would stop pushing HTTP/3 . HTTP/2 really is good enough. Clouldflare did a recent test where HTTP/3 was, at most, 4% faster. And sometimes it was slower. And I've seen other benchmarks with the same results. The only big advantage UDP based HTTP/3 provides over HTTP/2 is error correction without head of line blocking. And most connections including cellular already do error correction below layer 7 so it's mostly pointless.

https://blog.cloudflare.com/http-3-vs-http-2/

(Disclaimer: Googler on build tools).

I hear this argument a lot, and fail to be convinced. Optimizations at scale matter a lot. Let's posit that 100,000 developer-years have been spent implementing HTTP/2 and tools to interact with it. (Hopefully a great over-estimate). Let's say we have to spend all that again to move to HTTP/3. Is it worth it?

Well, per random internet stats I haven't validated, there are about 4b internet users, spending about 3h per day on the internet apiece. I could imagine 5% of that is spent on synchronous resource loading. That's about 10m/day/user - or about 28M years/year spent waiting on resources to load. A 1% savings (the minimum of CloudFlare's range) is 280k human years / year. And that's the bottom end - could be as high as 4% (1.1M years/ year), and without BBR (negatively impacting high packet loss and high throughput connections in particular).

Is "persons average time on the internet" comparable to "paid developer time"? No. A lot of that user time is timeboxed "wasted" time, in the endless content scroll. With that in mind, is it worth it overall? Probably. I've tried to estimate in favor of developers, but I still get their one-time effort paid back 2.8-11x _each year_ in user time, under unfavorable conditions. And this is growing rapidly, both in user count and time per user.

And that says nothing about the privacy benefits of encrypting headers and whatnot, which you should probably ascribe nonzero value.

This discounts the massive cost of switching to HTTP/3 . Plus, increases in internet speed would negate all the gains within a few years.

The massive switching cost of IPv6 has slowed deployment for a decade. Since it's so expensive to switch to HTTP/3, it only benefits large companies like Google. To smaller companies it's a cost.

Only 33% of the web is using HTTP/2, which came out 6 years ago. Any big gains we're talking about are many years in the future when internet speed will be maybe double what it is now. The slow adoption of HTTP/2 relative to its great benefits compared to HTTP/3 shows you how bad adoption will be.

Since 3 is single digits percent better than two, I bet adoption won't cross 20% for almost ten years. It's only going to be the FAANG'S of the world that think such as small increase in performance is worth the switching cost.

So that was kinda a rant but I don't think throwing out big numbers because so many people use the web is a strong argument. Users aren't the ones paying a large cost for a small performance increase

HTTP/1.1 is not being retired though, so I'm not sure I follow the argument about any forced switching cost for small companies. (Which I attempted to cover in my 100k estimate anyways, though you're free to dispute it). Off-the-shelf servers will implement it as an option if you want to turn it on, some clients will support it, and for the rest, status quo should hold? Not for some - e.g. firewall manufactures will presumably have to care - but the vast majority I don't really see being negatively affected by the existence of this standard.

Speed increases will presumably be consumed by continued bloat on part of publishers, as has historically happened in all tech innovations. Which might argue that it doesn't matter regardless and no optimization is ever useful, but that's both defeatist and ignores companies who do care (e.g. CloudFlare), for whom 4% probably matters now and will matter still in a decade.

I think you're seriously underestimating the number of systems that will be forced to deal with HTTP/3 if it's standardized. These days nearly everything uses HTTP. Changing HTTP is almost as big as adding another option to TCP/UDP

Everything that touches HTTP connections. Proxies, transparent proxies, web application firewalls, every network analysis and debugging tool, layer 7 load balancers.

There's probably half a million hardware firewalls out there that won't ever get a software update. As soon as http/3 is released, they're useless. The ones that can be upgraded need downtime and people time to do so. Just in firewalls this change could cost 400 million.

Realistically, the consequences of HTTP/3 will cost billions. Is 4% faster speed worth that? There's a lot of other ways to increase speed 4% without spending any money. Like turning on profile guided optimization in the browser, or just waiting a year for CPU and network speeds to increase that much.

I'm not being defeatist here, a maximum of 4% performance increase is just not very good. Nobody would switch a video or audio codec for a few percent, why is HTTP considered easier?

I say to Google: come back with something better. 20-30%? Totally worth it. If HTTP/2 is truly within 4% of optimal we should never touch it again

I'm hoping DNS-over-HTTP will use HTTP/3 to be back on DNS.

The error correction below layer 7 is a problem, because error in one stream blocks all streams, and lower levels of the stack can't help that.

On the other hand, the error correction below layer 7 does does head of line blocking anyways. DSL is a good example, when "interleave" is on it adds ~40ms of latency to reassemble packets.

Cellular is less severe but similar. Fixing head of line blocking at layer 7 won't un-interleave the packets.

> While HTTP/3 specification is still in the draft stage, the latest version of the Chrome browser already supports it by default

This is awful, because it means the spec review process does not have the impact that it can have, and Chrome gets to single-handedly define what they want the spec to be

Chrome has supported draft versions for the past few years already. The current spec is considered to be basically final and there are no more expected backwards compatibility breaks. Seems useful to get some widespread real-world experience in case there is actually something unexpected at a large scale.

That's simply false. Chrome introduced QUIC long before the standardization process, did IETF just take it wholesale? No. Look up "ietf quic vs google quic". Same here.

Correct. Furthermore, the motto of the IETF is "Rough consensus and running code". Someone needs to go ahead and implement specs while they're still in draft stage so people can actually use it, benchmark it and in some cases figure out problems that no committee of IETF engineers would have been able to predict.

Well, these kinds of technologies need to be tested at scale before being adopted. On the other hand, SPDY (HTTP/2) was given the same treatment and instead of fixing its issues / scrapping it entirely, we ended up with HTTP/3 a few years later.

SPDY was very similar but incompatible with HTTP/2, scrapping it for a better option was a good move, IMO (HTTP/2 is still alive and well in Chrome).

I am still waiting of a thorough comparison between HTTP/3 and Aspera. Has anybody attempted this yet?

Not a word about fairness/congestion control. What if throwing out decades of tuning congestion control is going to have consequences. Which, to put my tinfoil hat on, might lead to problems resolvable only by tiered traffic (and end of network neutrality).

(Disclaimer: Googler on build tools; Canadian)

Tiered how? By IP? With most content served by a CDN or DDOS shield already, that's arguably fine; most meaningful on the customer IP where you'd want fairness across customers anyways. Or do you mean internet providers will privilege their own content? Already happening, to the extent allowed by law (I'm looking at you, FCC). Not likely to change with HTTP/3 - empirically, needs to be addressed by regulation and not technology.

Is there an outbound proxy for HTTP/3?

It rubs me the wrong way how HTTP/3 is portrayed as a community engineering effort in a naive march of progress narrative when the reality is that it's only pushed by Google, making browser development even more of a pain. Also, server-side implementations are missing last I checked, so it'll only be available for the Google and maybe Cloudflare fake web a la AMP. HailCorporate!

After reading title I hoped for some insights on changes in HTTP/3-spec which delay finalization. Alas

Please don't implement HTTP/2 and HTTP/3. Unless you are working on Firefox or some other thing that should compete with Chrome.

Complicated protocol, unfriendly to hackers, offering huge corporation some millisecond savings to enforce their walled garden supremacy.

I actually view HTTP/2 as a great equalizing force for smaller players: It is perfect for "hiding" latency, so you are not forced to use a CDN like Cloudflare just to be closer to your user.

Example: I run a service without a CDN, but I only host it on dedicated servers located in Europe. Per-request latency is OKish for users in the US, but my service makes dozens of subrequests to the same origin when loading pages (images, XHR calls). Without HTTP/2, the user-experience for US customers would be abysmal and I'd be forced to reach for a CDN which has a PoP closer to them.

https://http2.golang.org/gophertiles?latency=200 and https://http1.golang.org/gophertiles?latency=200 perfectly demonstrate the issue I'd be facing otherwise. 200ms latency from the US West Coast to Europe is realistic, and the number of subresources being requested is also realistic for my application. If you don't believe the latency, try services like these: https://cloudpingtest.com/digital_ocean and https://pingtestlive.com/digitalocean-ping

I think both protocol upgrades are misunderstood:

HTTP/2

Besides the performance improvements brought in HTTP/2 via compression of headers and ability to multiplex streams it also enables full-duplex communication (à la WebSockets) [1]. This is used for example in gRPC, making the protocol far more versatile than given credit.

[1] No, I'm not talking about Server Push.

HTTP/3

HTTP/3 should bring benefits in wireless connections where TCP disconnections are frequent. QUIC handles connection identification so frequent TCP disconnects or even changing IPs would impact much less an HTTP/3 connection. I don't have the benchmarks but I would expect HTTP/3 to shine in this scenario which is bound to be more and more relevant with mobile devices, 5G, etc... In ideal, wired network, conditions HTTP/3 is probably not going to bring any improvement maybe even worse performance considering how much effort must have gone to optimizing TCP.

For me, both upgrades have a raison d'être but that doesn't mean that they displace HTTP/1.1 of all use cases. If you don't care about the performance improvements or need full-duplex no need to use HTTP/2, if you are not targeting mobile networks no need for HTTP/3. Luckily protocol negotiation should be quite seamless.

As a general question: why I do have to configure any nginx server that I want to use websockets on to specifically use http 1.1 if 2.0 also has support for them?

WebSockets was defined in a way that was incompatible with HTTP/2. RFC 8441 defines a way of reconciling the two, and explains the nature of the problem in its introduction: https://tools.ietf.org/html/rfc8441#section-1. But I don’t believe any browsers has landed support for this yet. (In Chrome it’s been behind a flag for 2½ years with apparently no changes for the last two years. No idea what the hold-up is. https://www.chromestatus.com/feature/6251293127475200.)

To add a bit more information to what the sibling post provides. The original WebSocket handshake is done over HTTP/1.1, there is an RFC specifying how to perform the negotiation also over HTTP/2 connection but its support lacking.

On top of that, HTTP/2 itself can do full-duplex communication so it can be used as a replacement of WebSocket, no negotiation or protocol upgrade involved. This capability is rarely used though but is, for example, leveraged by gRPC which is able to do bidirectional streaming [1].

[1] https://grpc.io/docs/what-is-grpc/core-concepts/

> offering huge corporation some millisecond savings

millisecond savings for all their users, which adds up to saving man-years every day. It is literally preventing people wasting lifetimes of effort looking at loading spinners.

If you can do better, propose it, but don't force other people to waste lifetimes of effort otherwise.

HTTP 1.1 was good for long, long time.

It had major benefits like pure text protocol, that one could use even by doing telnet to webserver (I did that when I needed to debug some pesky issues), starting with HTTP 2.0 it all goes to binary protocol (there is a text one, but almost no browser supports it :( ).

And now, on top of that replace years of performance tuning TCP out of the window and use UDP, and invent TCP features on top of UDP.

Yes, it is faster (few percent, this is not a 50% increase, it is a mere 3%), but the benefits will be reaped by the largest of corporations.

Is it worth it? Maybe for end users (who will get their web page in 485 ms instead of 500ms), but for developers it is not.

I was expecting HTTP 3.0 to get us huge benefits, but the numbers that were posted few days ago in hacker news are so underwhelming that I just don't care for it at all.

And cost of development is high.

I, too, like to tell tacky tales of telnet tweaking. Some of them are even true.

But to consider those rare instances to be equal or exceeding the value of a significant across-the-board performance increase is ridiculous. As are your attempts at populism: even against specific arguments how the benefits are more meaningful for smaller websites, you repeat the assertion that “the benefits will be reaped by the largest of corporations”. At least you have the decency to immediately contradict yourself.

> the value of a significant across-the-board performance increase

Extraordinary claims require extraordinary proof.

Please read section about comments at https://news.ycombinator.com/newsguidelines.html

Thanks

I am not sure I understand your concern, couldn't someone just develop a console app that can traverse the protocol? I am with you in the enjoyment of the simplicity of HTTP/1.1 but I don't agree that this particular concern is large enough to slow adoption.

It is a complex, stateful (!!) protocol with non-trivial state-machine. A "console app" won't cut it. Even Wireshark might not cut it. Thanks to things like quick start, TLS session tickets and server push you won't understand what are you even looking on 90% of time.

When HTTP 1.1 fails, your browser shows you a proper error message. When HTTP 2/3 fails, it is always "a protocol format violation". What violation? Why? Who knows.

> I don't agree that this particular concern is large enough to slow adoption

Sure thing. Kerberos is still alive and kicking. SMB 1 is built into every appliance. SOAP is the protocol of choice for corporations...

Complexity never slows down adoption of <insert name of utter turd technology>, because such technology is generally being pushed down people's throats by someone else. If Google does not push HTTP 3 slower, it's adoption won't slow down. The quality of tech plays no role in that.

I disagree with the idea that this is being "pushed down people's throats". It's another protocol and nothing has been published stating that HTTP/1.1 support is going anywhere.

A protocol format violation notice could tell you what was wrong it just hasn't been developed to the full extent to do so. Give browsers and tools time to develop and be built to properly debug the connection.

Maybe for end users (who will get their web page in 485 ms instead of 500ms), but for developers it is not.

If the users see the benefit then the companies that the developers work for will find a new competitive advantage, which benefits the developers (higher profit, better job security, etc).

It's impossible for one group to benefit without the other group also benefitting.

>but the benefits will be reaped by the largest of corporations.

What isn't?

But you're also ignoring the fact that these benefits will also be reaped by end-users - and more by people who have poor connections to the Internet.

>Is it worth it? Maybe for end users (who will get their web page in 485 ms instead of 500ms), but for developers it is not.

The Internet is for End Users,[0] not for developers. UX >>> DX.

[0] https://tools.ietf.org/html/rfc8890

My concern is that the benefit is minor, 3% faster web page download?

And I wrote that big corporations, because those have millions of users, if users download faster then they can server even more users on smaller amount of hardware. 3% less hardware, that might be big if you are big.

And considering it is developed by Google and pushed into Chrome they will get that benefit sooner than others.

No, TCP has been bad for a long long time. TCP has never worked on dodgy internet connections. TCP often completely stalls on bad connections.

I don’t like this argument because it’s not like the extra milliseconds are going to make peoples lives more productive/happy/meaningful, even in aggregate. But if you are going to make this argument, one could also argue that it’s better to spend that time looking at loading spinners than looking at Facebook ads.

I can do better. Get rid of React and the other client-side libraries that reimplement the DOM interface in Javascript except slower and more brittle.

For what it’s worth, I’ve been profiling front end applications for over a decade, and the only time application bundle size was a real problem was very rare. On the other hand, people writing terrible code usually was the problem, and it would have happened with or without react.

I think we’d see faster websites more often if developers had worse computers, or they invested more time in testing in resource constrained environments. I really don’t think react (or similar) is the core problem.

Who said anything about bundle size?

There's already a "browser platform framework", it's standard, built into your browser and very fast.

Trying to re-implement the browser inside the browser using Javascript is a recipe for disaster. (Indeed: witness the "modern" web.)

I get that something more enterprisey-feeling with more knobs for programming in the large is more agreeable to the assembly-line programmer in large IT shops, but if you want your browser apps to act nice you'll have to suck it up and program natively without the overhead of a framework.

This, absolutely. Every developer should get like a Pentium 3 500 MHz and 512 MB of RAM to make their software work.

> unfriendly to hackers

I think this is quite an important point. If the protocol is so complex such that creating custom implementations is prohibitive then that's an issue, and also perhaps a 'smell'

It's easier to create correct HTTP/2 implementation than HTTP 0.9/1.0/1.1

I had enough weekends wrecked by someone thinking they can implement HTTP themselves, only to find out that no, they couldn't, and that was for cases that didn't even hit corners. A netcat "HTTP server" demo is cute, but the power of the computer is that we make tools to make tools that can cover things like HTTP/2 reasonably fast - and much more correct.

Yes, I've fallen into the 'HTTP/1* is simple' trap myself.

Could you go more in depth? What project do you work on? What sort of interop issues have you encountered?

FWIW, I have encountered tons of issues in peoples' "this is easy, right?" implementations of 100 Continue (including in some at-the-time major Ruby HTTP servers), non-ASCII encoding in HTTP headers (which has a ton of subtle rules, and just throwing around UTF-8 is not correct), and chunked Transfer-Encoding (though I can't remember what was wrong); further, people often don't even realize HTTP trailers exist at all, which is a bit infuriating :/. (Note, though, that I am still 100% on the side of the anti-HTTP/2 camp in this thread.) The core problem is that somehow people think they can implement a spec without even, you know, reading the spec, which is so far past hubris as to have gone through incompetence into obvious negligence.

Usually the whole 3xx series of return codes, also any 2xx that isn't 200 and 204.

If I find someone's "quick and dirty HTTP client library", I generally lose hope that redirects are handled. Anything more complex than that (and there's a lot!) is pipe dream.

HTTP 2 is faster though. Especially over mobile networks.

Simple doesn't always mean better.

Not just "simple" - broken, like all "bang it out on pseudo serial port" protocols of IETF nature.

The text nature makes it easy to implement a broken client or server in a hobbled development environment, yes. It also creates a legacy of brammage that is impossible to fix without significant break in protocol like HTTP/2 is.

Shortly speaking, Postel's Law Considered Harmful (in network protocols, at least)

IETF protocols being YOLO is exactly what makes them so attractive. The web never would have been a thing if it needed to be built on something highly correct and ordered like Signalling System No. 7.

SS7 is pretty bad comparison.

OSI stack is better, but usually you'd build on top of higher-level components of it, not "supposedly text but honestly binary" protocol like HTTP.

Being YOLO resulted in it taking over 15 years for email to not have random crashes involving my native language (and it's pretty simple, as it has no multibyte requirements).

YOLO is how the internet has been broken through multi-level NAT, because ca 1980 someone convinced other that for "temporary test deployment" only 32bits will manage.

YOLO is why transition to IPv6 takes ages even when higher level protocol wouldn't even notice, because ~1983 in panic someone made an emergency, student-made port of TOPS-20 TCP/IPv4 interface and we're left picking the pieces forever.

And yes, HTTP and other "text" protocols are essentially binary protocols, because you end up dealing with whatever binary constant form someone put into client/server code. If someone goes too far into treating it as text when sending, suddenly you have a problem of dealing with missing record terminators. Standard header names could be just as well binary, except there's extra variation both possible (if you want to follow Postel's law), and spec (details of encoding).

I'm sorry you lost your faith in the Internet. If it makes you feel any better, I'm a Hurricane Electric certified IPv6 sage and I implement text-based telecommunications protocols so well that even Chinese operators use my code, because they like to implement creative extensions like the ones you describe, and the stuff I write is just so generalized that it can smoothly / easily enable that multitude of visions. Why? Is it because I'm unique? No. It's simply because my work follows the same free-spiritedness that's always guided IETF publications. They built us the best of all possible internets, and nothing, including IPv4 address exhaustion, is going to change that.

> It also creates a legacy of brammage that is impossible to fix without significant break in protocol like HTTP/2 is.

Isn't also HTTP/3 a significant break in protocol compared do HTTP/2 ?

From what I remember on HTTP/3 vs HTTP/2,main differences are due to different transport layer - in fact yiu can even use QUIC without HTTP. The HTTP part are mostly lifted from HTTP/2

You would rarely implement HTTP/1.x yourself. You could, but there are dedicated libraries for that.

I still find myself connecting with a line-buffered client to GET / and so on, from time to time. Even in 2020 it's still the handiest way to diagnose some issues.

I've always appreciated that most IETF protocols are text-oriented with line-buffered commands, and the option to speak the protocol directly in this fashion contributed enormously to my own understanding of SMTP, POP3, IMAP, IRC, NNTP, HTTP, FTP et al, and I always regretted not being to do the same with LDAP, SNMP, or BGP.

I can support the sentiment, but now when every public facing HTTP endpoint is TLS-protected... That ship has sailed. On internal networks HTTP/1 is not going anywhere any time soon, so there's that.

For TLS-wrapped protocols I'll use openssl s_client or ncat or some other simple stdin/out-friendly wrapper. There's no need to abandon line-oriented text-based application protocols just because the next layer down has a binary structure. After all, I'm not crafting TCP segments by hand.

I recommend that internal network services use HTTPS, there's plenty of reason not to lower your standards internally.

Reply on news.ycombinator.com