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

41–50 of 144 posts

Re: HTTP/2 Is Done

#41

Post by frankzinger »

jamescostian wrote: post #11
lazyloop wrote: post #6

Earlier quoted context omitted.

Poul-Henning Kamp (the author of Varnish) explained it best. http://queue.acm.org/detail.cfm?id=2716278

Do you have another explanation which hasn't been torn apart by Hacker News commentators already? As someone who would like to avoid going to the trouble to implement HTTP2, I'm not being sarcastic - I truly want to know why HTTP2 is so bad, and I want to read it from someone who backs up their words with cold-hard facts

Have a look at the W3 HTTP WG mailing list. PHK and others voiced all of their objections there in detail over a long period, and you can also read the rest of the WG's responses: https://www.w3.org/Search/Mail/Public/advanced_search?keywor... (all of PHK's posts to the list, in chronological order).

Re: HTTP/2 Is Done

#42

Post by frankzinger »

bsdetector wrote: post #39
asuffield wrote: post #18

Earlier quoted context omitted.

I followed the thread a little further, and the response seemed reasonable: experiments were run on this idea, it didn't seem to help, and nobody (including phk) has offered any further evidence to the contrary since then. I think you need to expand a little more on why you feel this is a "known flaw".

A 60 page document to explain how to compress text name/value pairs that are mostly unchanged between requests is "reasonable"? A static compression table with proxy authentication fields in it, as if the network between your browser and LAN proxy is somehow the bottleneck, is reasonable? This is a most over-engineered protocol, one where nobody knows how tables were constructed or from what data and nobody can quant…

> For instance how much is saved by using a huffman encoding instead of a simple LZ encoding or simple store/recall or not compressing it? Nobody knows!

It's not all about compression ratios. From the HPACK spec (https://http2.github.io/http2-spec/compression.html#rfc.sect...):

  SPDY [SPDY] initially addressed this redundancy by 
  compressing header fields using the DEFLATE [DEFLATE]
  format, which proved very effective at efficiently 
  representing the redundant header fields. However, that
  approach exposed a security risk as demonstrated by
  the CRIME attack(see [CRIME]).

  This specification defines HPACK, a new compressor for
  header fields which eliminates redundant header fields, 
  limits vulnerability to known security attacks, and which
  has a bounded memory requirement for use in constrained 
  environments. Potential security concerns for HPACK are
  described in Section 7.

Re: HTTP/2 Is Done

#43

Post by jmspring »

bgentry wrote: post #16

It's time to begin the long process of unwinding all the hacks that we've built to make HTTP/1.1 fast. No more concatenation of static assets, no more domain sharding. The future looks more like this, as the default, with no special effort required: https://http2.golang.org/gophertiles May nobody else have to suffer through writing an interoperable HTTP/1.1 parser!

Try hacking together a rudimentary one over a socket opened by AT commands. Embedded programming including cellular modems for the win, Bob.

Re: HTTP/2 Is Done

#44

Post by Kalium »

megaman821 wrote: post #29
tptacek wrote: post #26

Earlier quoted context omitted.

"Standardize authentication"?

Well Basic Auth exists now, but it is unusable for most sites due to several well-documented shortcomings. Surely something could be done to improve upon it.

Like kicking it up to the application layer?

Re: HTTP/2 Is Done

#45

Post by bsdetector »

frankzinger wrote: post #42
bsdetector wrote: post #39

Earlier quoted context omitted.

A 60 page document to explain how to compress text name/value pairs that are mostly unchanged between requests is "reasonable"? A static compression table with proxy authentication fields in it, as if the network between your browser and LAN proxy is somehow the bottleneck, is reasonable? This is a most over-engineered protocol, one where nobody knows how tables were constructed or from what data and nobody can quant…

> For instance how much is saved by using a huffman encoding instead of a simple LZ encoding or simple store/recall or not compressing it? Nobody knows! It's not all about compression ratios. From the HPACK spec ( https://http2.github.io/http2-spec/compression.html#rfc.sect... ): SPDY [SPDY] initially addressed this redundancy by compressing header fields using the DEFLATE [DEFLATE] format, which proved very effectiv…

The Huffman code is optional and the spec says not to use it on sensitive fields (no mention of what those are). You can use a separate LZ on each header field, compressing really long headers and not having information leak between headers and the bodies. You think they tested that? Or did the people who didn't know about CRIME in the first place just react? Where are the numbers that show a static huffman code that was created from some unknown dataset at one point in time and can't be extended because there's only a single "compress or huffman" bit in the protocol is needed? Like I said, insane.

Re: HTTP/2 Is Done

#46

Post by Intermernet »

RunningWild wrote: post #37

Another year, another wheel reinvented.

I know you're being somewhat facetious, but have you considered how much the wheel has actually been reinvented?

The first wheels were probably logs under rocks. Then axles got developed, then spokes, then tyres etc.

Everything from the gyroscope to the LHC can attribute it's beginnings to the humble wheel.

Reinvention is, if not always good, always admirable.

Re: HTTP/2 Is Done

#47

Post by stephenr »

mark242 wrote: post #20
jamescostian wrote: post #11

Earlier quoted context omitted.

Do you have another explanation which hasn't been torn apart by Hacker News commentators already? As someone who would like to avoid going to the trouble to implement HTTP2, I'm not being sarcastic - I truly want to know why HTTP2 is so bad, and I want to read it from someone who backs up their words with cold-hard facts

"As someone who would like to avoid going to the trouble to implement HTTP2 (...)" Good luck with that. Google has been incredibly adept at using the leverage of their search engine to make webmasters adhere to best practices. ("mobile friendly" e-mails lately, anyone?) Once HTTP/2 lands as a default in Chrome, Apache, Nginx, and Netty, of course they'll push HTTP/2-friendly sites higher in search results.

I think you meant to say "Googles definition of best practices"

Re: HTTP/2 Is Done

#48

Post by stephenr »

MichaelGG wrote: post #34
ecthiender wrote: post #32

Earlier quoted context omitted.

Excuse my ignorance, but how can I do session management without using cookies? I tried searching on the net, but it doesn't seem to give any concrete/valid results. Can you give me any pointers? Edit: I do use OAuth2.0 on my services and use Mozilla Persona to manage user logins, but I am not clear how can I keep sessions between requests if I don't use cookies.

HTML5 has local storage, so you can put auth tokens in there and only send them when you need them, versus on every request.

So rather than just using cookies effectively, you can make your application absolutely dependant on both JavaScrip and XHR?

Re: HTTP/2 Is Done

#49

Post by derefr »

bgentry wrote: post #16

It's time to begin the long process of unwinding all the hacks that we've built to make HTTP/1.1 fast. No more concatenation of static assets, no more domain sharding. The future looks more like this, as the default, with no special effort required: https://http2.golang.org/gophertiles May nobody else have to suffer through writing an interoperable HTTP/1.1 parser!

The real problem, I think, will be moving to "idiomatic" HTTP2-centric design (lots of little resources, relying on parallel chunked delivery and server-suggested retrieval) while still keeping HTTP/1.1 clients fast.

I'm betting there will come a polyfill to make HTTP/2 servers able to deliver content to HTTP/1.1-but-HTML5 web browsers in an HTTP/2-idiomatic way—perhaps, for example, delivering the originally-requested page over HTTP/1.1 but having everything else delivered in HTTP2-ish chunks over a websocket.

Re: HTTP/2 Is Done

#50

Post by Mojah »

bgentry wrote: post #16

It's time to begin the long process of unwinding all the hacks that we've built to make HTTP/1.1 fast. No more concatenation of static assets, no more domain sharding. The future looks more like this, as the default, with no special effort required: https://http2.golang.org/gophertiles May nobody else have to suffer through writing an interoperable HTTP/1.1 parser!

If at any point you need a reference guide of all the HTTP/1.1 hacks that we {could,should,would} change for HTTP/2, I found the following post really useful: http://ma.ttias.be/architecting-websites-http2-era/
Post reply on HN