Hacker News Reader

Comment by secondcoming | Hacker News Reader

> 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'

View on HN

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.

Reply on news.ycombinator.com