Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

HTTP/2 Is Done

mnot.net

Post reply on HN
Print view View original

121–130 of 144 posts

Re: HTTP/2 Is Done

#121

Post by entropy_ »

peterfirefly wrote: post #99
TylerE wrote: post #96

Earlier quoted context omitted.

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.

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?

Probably not, most, if not all, non-compliant XML/XHTML is either written by hand or by very bad generation tools. In the case of HTML/2 it's a protocol that needs to be implemented by browsers and web servers and there are only so many of those. In the case of XML/XHTML any person throwing up a website or sending a document does the generation with a different set of tools(or by hand)

Re: HTTP/2 Is Done

#122

Post by jimktrains2 »

youngtaff wrote: post #85
EugeneOZ wrote: post #70

Earlier quoted context omitted.

nginx doesn't support http2, apache too.. So maybe it's time to make some efforts to implement it on servers first. Maybe make some donations to apache, nginx dev. teams to speed up this process.

This is my real worry, at least nginx supports SPDY so has a base to evolve from, Apache support appears to be in a really bad place last time I checked.

The two most largely deployed servers on the Internet don't have HTTP2 support so their experience implementing and using it was never factored into the protocol.

And people wonder why I don't like it.

Re: HTTP/2 Is Done

#123

Post by byuu »

stephen_g wrote: post #90
byuu wrote: post #65

Earlier quoted context omitted.

> May nobody else have to suffer through writing an interoperable HTTP/1.1 parser! Yes, now it'll be much easier than parsing plain-text. Now they just have to write a TLS stack (several key exchange algorithms; block ciphers; stream ciphers; and data integrity algorithms); then implement the new HPACK compression; then finally a new parser for the HTTP/2 headers themselves. Now instead of taking maybe one day to wri…

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 g…

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

Re: HTTP/2 Is Done

#124

Post by frnucz900 »

iopq wrote: post #69
byuu wrote: post #65

Earlier quoted context omitted.

> May nobody else have to suffer through writing an interoperable HTTP/1.1 parser! Yes, now it'll be much easier than parsing plain-text. Now they just have to write a TLS stack (several key exchange algorithms; block ciphers; stream ciphers; and data integrity algorithms); then implement the new HPACK compression; then finally a new parser for the HTTP/2 headers themselves. Now instead of taking maybe one day to wri…

HTTP/2 is easier to parse than HTTP/1.1 because there's less edge cases Also a bonus: no more "Referer" (sic)

No referrer header at all, or did they fix the spelling? I looked in the HTTP/2 spec quickly and didn't see a mention but I could be missing something..

Re: HTTP/2 Is Done

#125

Post by bgentry »

carsonreinke wrote: post #95
stephen_g wrote: post #90

Earlier quoted context omitted.

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 g…

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

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.

Re: HTTP/2 Is Done

#126

Post by byuu »

TylerE wrote: post #96
carsonreinke wrote: post #95

Earlier quoted context omitted.

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

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.

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

Re: HTTP/2 Is Done

#127

Post by bgentry »

hueving wrote: post #52
bgentry wrote: post #33

Earlier quoted context omitted.

If anyone wants to learn more about optimizing for HTTP/2, unwinding HTTP/1.1 hacks, and strategies to optimize for both versions at the same time, Ilya Grigorik's "High Performance Browser Networking" is an excellent resource: http://chimera.labs.oreilly.com/books/1230000000545/ch13.htm...

If it requires a book to optimize for HTTP2, doesn't that counter your comment's parent's point? It's supposed to be simple.

It requires a small section in a book to tell you how to undo all the tricks you've had to learn in the past 10 years to make an HTTP/1.1 website fast. Most of that is irrelevant and detrimental with HTTP/2, which is kind of the point. You'll get the benefits of those optimizations without having to do anything special to get them.

That book is also a phenomenal resource on the performance of all things web-related, so you should check it out regardless of any concerns you have about HTTP/2.

Re: HTTP/2 Is Done

#128

Post by orthecreedence »

Question: I originally heard HTTP/2 would force TLS and have it baked into the protocol. Is this still the case? If so, is this going to be strictly enforced? I think it's a really terrible idea to melt a protocol and a transport together. Or am I misunderstanding how it works?

Re: HTTP/2 Is Done

#129

Post by garraeth »

orthecreedence wrote: post #128

Question: I originally heard HTTP/2 would force TLS and have it baked into the protocol. Is this still the case? If so, is this going to be strictly enforced? I think it's a really terrible idea to melt a protocol and a transport together. Or am I misunderstanding how it works?

This says yes for Chrome and FF but no such requirement for cURL or IE: http://daniel.haxx.se/http2/

How accurate it is, I'm not sure.

Re: HTTP/2 Is Done

#130

Post by TylerE »

byuu wrote: post #126
TylerE wrote: post #96

Earlier quoted context omitted.

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.

> 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 funct…

It's still a much better situation than HTTP/1.1. At least an HTTP/2 compliant implementation has an exact definition, that it either is, or isn't. An HTTP/1.1 implementation has a vast number of corner cases and optional bits.

Sure, if you're out-of-spec, all bets are off. It's just that with hTTP/1.1 even 100% in-spec implementations are a pretty wide target zone.

Post reply on HN