The value of being able to build an HTTP 1.1 server is not in putting a hand-crafted server on the internet and serving traffic. It's in the experience of building the server and later applying that detailed byte-by-byte knowledge in real work. It's also in teaching young engineers that yes, they can learn something by digging into the layers that surround their own code. Part of the dysfunction of "enterprise" programming is the programmed helplessness of people who are surrounded on all sides by complex, opaque technology that turns curiosity into a liability. We are replacing a "whoa, I can see how it works!" experience with a "fuck, I guess have to leave this part to those bigcorp engineers" experience.

(I'm not agreeing with the author, just pointing out why he might care about the ability for an individual to implement the protocols the web is built on.)

I agree it's incredibly important to dig into layers under (and over) the one you're working at! I'm very grateful for the experience of building a simple unix-like kernel and a simplified TCP & IP implementation as school projects. And I'd encourage anyone to do the same with HTTP 1 or 2 or 3. The difference is that no one thinks that their educational/toy TCP implementation is suitable for production use, while people do seem to (mistakenly) think that about HTTP.

> IMO, one of the benefits of HTTP 2 and 3 is they force people to use libraries

What a strange comment. "The benefit of this protocol is that it's so complex that nobody understands it, so they have to use an existing implementation."

Bram Cohen made a similar observation[0] years ago.

Bram's Law - The easier a piece of software is to write, the worse it's implemented in practice.

I'm not sure whether I agree with him but it's not obviously wrong.

[0] https://web.archive.org/web/20170629144859/http://www.advoga...

What a weird slippery slope argument. There is a world of difference between "so complex that nobody understands it" and "I can telnet to port 80 and fetch a webpage using keyboard and fingers"

That's pretty much in the "cut out future generations from system programming for the web" territory, and complexity for the sake of complexity. Also, you have to implement HTTP/2 in addition to HTTP/1.1.

It's a big jump to go from "this protocol is more complicated than the previous one" to "cut out future generations from system programming". It's not _that much_ more complicated that a competent programmer who's familiar with sockets and bytes can't ever accomplish it.

As discussed at length in another sub-thread here, the complexity solves real problems, it's not for its own sake. But if you're not convinced of that, nothing I say here is going to change that.

·

If you've worked with me, you'd know that I take simplicity as a virtue to an extent that's almost detrimental to getting stuff done. I despise complexity for its own sake. I wish as much as anyone that we could start over and redesign IP, TCP, TLS, HTTP, HTML, JS, and a few more things, with all our accumulated knowledge, into a simple and clean application and content distribution system that's easy to understand and observe. But path dependence :( We have to work with what we've got.

It's the picking out of HTTP 1.1 as some sort of golden age of clean and simple and observable that bothers me. It isn't.