undefined | Better HN

0 pointsstephen_g11y ago0 comments

Have you tried writing anything more than a very simple HTTP/1.1 parser/server? It's actually not as easy as it seems at first - edge cases everywhere, different user agents doing subtly different things, etc. etc.

Your argument is invalid in my opinion. HTTP/1.1 is not simple to implement to any decent level of completeness and correctness, and HTTP/2 does fix a fair few things.

Anyway, there are already plenty of good tools for debugging HTTP/2 streams (Wireshark filters, etc.), and there's only going to be plenty more as time goes by.

0 comments

byuu11y ago

> Have you tried writing anything more than a very simple HTTP/1.1 parser/server?

Honestly? No. I wrote an HTTP server that runs my site just fine. It also functions as a proxy server so that I can run Apache+PHP (for phpBB) on the same port 80. (The reason I don't just use Apache is that I generate my pages via C++, because I like that language a hell of a lot more than PHP.) I also have had the HTTP client download files from the internet for various projects (my favorite was to work around a licensing restriction.)

I get around 100,000 hits a month, and have not had any problems. If you think issues will arise when I start reaching into Facebook levels of popularity ... I'm sure they will. But, I'll never get there, so to me it doesn't really matter.

So for my use case, HTTP/2 is unbelievably more challenging and costly to support. Especially as I have about seven subdomains, and nobody's giving out free wildcard SSL certs.

I also didn't even say the added complexity is a bad thing+. Modern Windows/Linux/BSD are infinitely more complex than MS-DOS was, too. I was just pointing out that the OP's elation was misguided. (+ though to be fair, I do believe things should be kept as simple as is reasonable.)

Also, I strongly challenge this notion that you have to be 100% standards-complaint with the entire RFC to run an HTTP/1 server successfully. Because not even Apache is remotely close to that. The mantra is liberal on your input, conservative on your output. And everyone follows that. And as a result, no major projects out there are spitting out headers split into 300 lines using arcane edge cases of the RFCs.

cperciva11y ago

HTTP/1.1 is only complicated if you want to support all of the optional features.

carsonreinke11y ago

So won't HTTP/2 have these edge cases also?

bgentry11y ago

No. Most of the edge cases arise from trying to parse an underspecified plaintext protocol. Everything in HTTP/2 is length-prefixed and unambiguously specified. That makes it dramatically easier to write a compliant parser or client.

TylerE11y ago

Essentially, no.

HTTP/1.1 contains tons of optional features. Practially no two implementations support the same set.

HTTP/2 is all 100% mandatory. Any compliant HTTP/2 implementation will support an EXACT set of known features.

peterfirefly11y ago

Won't that create the same problems as XML and XHTML where full compliance is/was mandatory -- and the reality turned out to be different?

1 more reply

byuu11y ago

> HTTP/2 is all 100% mandatory

That's a nice idea in theory, but what makes you think anyone is going to adhere to that?

Developers have always, and will always, do whatever they want when they implement your standards.

It was bad enough that when I worked on a binary delta patching format, I made sure there were absolutely zero possible undefined values, because I knew someone might try and use them to add new functionality in.

For something as complex as HTTP, I can guarantee you people will ignore parts of the spec they don't care about. And you can yell at them and say it's not a valid/legal HTTP/2 implementation, but they won't care. They'll keep on doing what they're doing.

1 more reply

bhouston11y ago

> HTTP/2 is all 100% mandatory. Any compliant HTTP/2 implementation will support an EXACT set of known features.

But over the next couple of years, won't people come up with new ideas and add them as optional extensions? How is that handled?

I suspect some of these optional extensions will be really useful in special cases such as support for LZMA/LZHAM compression in addition to just gzip.

2 more replies

j / k navigate · click thread line to collapse

0 comments

byuu11y ago

> Have you tried writing anything more than a very simple HTTP/1.1 parser/server?

So for my use case, HTTP/2 is unbelievably more challenging and costly to support. Especially as I have about seven subdomains, and nobody's giving out free wildcard SSL certs.

cperciva11y ago

HTTP/1.1 is only complicated if you want to support all of the optional features.

carsonreinke11y ago

So won't HTTP/2 have these edge cases also?

bgentry11y ago

TylerE11y ago

Essentially, no.

HTTP/1.1 contains tons of optional features. Practially no two implementations support the same set.

HTTP/2 is all 100% mandatory. Any compliant HTTP/2 implementation will support an EXACT set of known features.

peterfirefly11y ago

Won't that create the same problems as XML and XHTML where full compliance is/was mandatory -- and the reality turned out to be different?

1 more reply

byuu11y ago

> HTTP/2 is all 100% mandatory

That's a nice idea in theory, but what makes you think anyone is going to adhere to that?

Developers have always, and will always, do whatever they want when they implement your standards.

1 more reply

bhouston11y ago

> HTTP/2 is all 100% mandatory. Any compliant HTTP/2 implementation will support an EXACT set of known features.

But over the next couple of years, won't people come up with new ideas and add them as optional extensions? How is that handled?

I suspect some of these optional extensions will be really useful in special cases such as support for LZMA/LZHAM compression in addition to just gzip.

2 more replies

j / k navigate · click thread line to collapse