> Seriously: this guy seems to believe that the correct way to implement something is with a massive set of examples and test cases, where you massage your implementation until all of the examples work right and all the tests pass.

You have no idea how common that utterly bonkers way of thinking is. I have a colleague according to whom every protocol is trivial to implement. Why? "Trace what an existing implementation does, and replace the values. It works"

> I have no sympathy for someone who reads the descriptive parts of the specification, trying to build their implementation from examples, and then ignores the machine-parse-able, normative grammar at the bottom: if you aren't reading the specification, you are not qualified to build a server for it.

I don't think it invalidates any of his other points. The important thing to get is that implementing a valid HTTP server (or client) takes a lot of work and is not made trivial by how the RFC is built. Lots of people have thought it would be and are still fixing bugs years later.

Getting the syntax parsing right is just one part of the job. Most of the issues come with the semantic and as he shows, the violations in layering. Here is an example of the state machine to implement to make your web-server semantically correct: http://wiki.basho.com/images/http-headers-status-v3.png . The schema is complete but still misses Keep-Alive, Range requests, Chunked encoding, ...

Yes: I agree that these standards are complex; in some cases, I believe these standards even are poorly designed (although I try to reserve judgement until I've "thought through the problem" for at least a few years, and until I've spent enough time reading through documents from the era trying to figure out why a specific feature was designed the way it was); in a handful of cases I even have direct evidence to conclude the people who drafted the spec were disappointed with the result: however, whining about the complexity of a specific set of semantics while indicating a disdain for even reading the entire specification... there is simply no reason to trust the resulting conclusions (and you really are just trusting him: he doesn't put any of these things into context or explain how they are problematic to implement).

Some things in life are complex and some of those things actually had to be fairly complex (maybe not as complex as they are) to handle their myriad goals. In the case of HTTP, there are tons of things people want to be able to do: all of those headers he is complaining about do something, and as someone who uses HTTP quite often I am honestly not certain which ones I'd be willing to live without... you could always encode them differently, but that's again just a syntax problem: the semantics of a distributed document database that is flexible enough to support the notion that people speak different languages, that file formats go in and out of style, that you may want or need third-parties to proxy information for purposes of either filtering or improving performance and yet at the same time allows for state to be persisted and only sometimes shared on cached documents... this is a hard problem, and when "lots of people have thought it would be [trivial]" they are just being naive, and I'd go so far as to say "disrespectful" of the hard work put in by the people who came before them in the attempt to design these specifications.

To then respond to one of the specific points you made, the "violations in layering", this guy's proposal is itself a layering violation (something I had originally spent some time complaining about in my first post, but then removed as I realized there was no point defending implementation details from someone who doesn't feel people should read the spec): imagine what it would mean to have these kinds of requests coming through a proxy server... what does the proxy server do about the state? You either have the proxy treated as a pass-through, in which case the state is going to get highly muddled and require one-to-one connection mapping through the proxy, or you are going to have the proxy handle its own state, which will ruin the performance benefits of not having to do multiple round-trips (as the proxy will have to wait for the previous request to come back before sending the new one).

Even if he did have something actually better, the people who built these specifications that he's ranting about had the really hard problem of getting a bunch of people who had differing ideas about what they were willing or wanting to implementing and had varying amounts of resources and ability to alter existing systems; honestly, I think they've done a great job on the whole, and I have absolutely no faith that if this guy were somehow in their place that we would have ended up with something different, and certainly not something better. The idea that someone then just spends a bunch of time ranting about the work these people did (or even the real-world complexities that the people working on Apache httpd ran into that caused them to end up with some of the specific incompatibilities mentioned) without really painting a picture of the original context, finding out what the various challenges and goals were, and then pointing out specific ways the result could have worked out differently with the available information. As it stands, this is just textbook de-motivational whining. :(