Hello HTTP/2, Goodbye SPDY • Hacker News Board

Re: Hello HTTP/2, Goodbye SPDY

#161

Post by josteink » Tue, Feb 10, 2015, 11:17 AM UTC

donatj wrote: post #91

Can someone explain to me the actual upside of header compression? I work on a fairly major educational site and calculating now our request + response headers comes out to 1,399 bytes. Gzipping them they come out to 1,421 bytes. A small net increase. Am I missing something? Do some people have so many cookies that this makes a difference or something?

> Am I missing something?

Google has about 200 different tracking cookies with lots of redundancies which is compressed sufficiently better than that.

Google's aim with SPDY was to be able to track you across all HTTP-requests without the bloat of the tracking-cookies causing you to exceed a normal ADSL MTU-size and thus having the tracking cause packet-fragmentation and potentially reduced performance.

Possibly good goals for all the wrong reasons. And again it's Google's needs above those of the internet at large.

Re: Hello HTTP/2, Goodbye SPDY

#162

Post by gsnedders » Tue, Feb 10, 2015, 11:23 AM UTC

mnarayan01 wrote: post #141

totony wrote: post #109

Earlier quoted context omitted.

XHTML was an overall improvement to HTML imo. If you're going to use XML, at least be consistent with this choice. HTML was not, XHTML is.

Technically HTML was a derivative of SGML. That said, as someone who did a fair amount of parsing of old-timey HTML...it would have been really nice if it was XML.

Well, by the time the first spec was written it was defined to be an SGML application; when TimBL first implemented it, it was "roughly based on SGML". As far as I'm aware, except for the W3C Validator, no other serious HTML implementation treated HTML as SGML.

And it couldn't have been XML, because HTML predates it.

Re: Hello HTTP/2, Goodbye SPDY

#163

Post by gsnedders » Tue, Feb 10, 2015, 11:31 AM UTC

bsdetector wrote: post #160

enneff wrote: post #148

Earlier quoted context omitted.

HTTP pipelining is busted for a variety of reasons. Support exists in most browsers but it's disabled by default because it makes things worse, on balance.

At the time SPDY came out, Opera and Android Browser had pipelining on by default and Firefox was about to also default it on. They didn't only because of the promise of SPDY, not because pipelining "is busted". Pipelining works fine in almost all cases. And if you only enable pipelining to known-good servers over a non-MITM SSL connection -- exactly like SPDY does -- then there is absolutely no problem with it and i…

Firefox wasn't about to default it to being on (yes, there was work being done on it to see how workable it was, but there was no decision to ship it) — it's well-known that pipelining causes all kinds of bizarre breakage with badly behaved servers and proxies (and the latter are where the implementations are especially bad).

Opera had enough problems with pretty crazy-complex heuristics as to when to enable pipelining; it would've been nice for them to have been published, but that has never happened. Determining what a known-good server is over SSL isn't that easy.

Re: Hello HTTP/2, Goodbye SPDY

#164

Post by Kurtz79 » Tue, Feb 10, 2015, 11:45 AM UTC

runeks wrote: post #152

drderidder wrote: post #54

I got a copy of Paul-Henning Kamp's critique "HTTP/2.0 - The IETF is Phoning It In" off the ACM website before the link went dead. Here's a bit of what he said about it: "Some will expect a major update to the world’s most popular protocol to be a technical masterpiece and textbook example for future students of protocol design. Some will expect that a protocol designed during the Snowden revelations will improve the…

> This is almost triply ironic, because the major drags on HTTP are the cookies, which are such a major privacy problem, that the EU has legislated a notice requirement for them. Which, of course, is useless, since any browser supports turning off cookies. As an EU citizen, my experience of this regulation is simply that I have to click "OK" to accept cookies on all the EU sites I visit. I apologize if this comes off…

My experience is the same, with an added facepalm everytime I see it.

It is a EU thing then ? It appears or not depending on the origin ip address of the request ?

Re: Hello HTTP/2, Goodbye SPDY

#165

Post by jimktrains2 » Tue, Feb 10, 2015, 1:49 PM UTC

frankzinger wrote: post #137

jimktrains2 wrote: post #106

Earlier quoted context omitted.

> Whatever PHK wants it to be, HTTP/2 is a great step forward from where we are today. A hugely bloated, binary protocol is better than the simple, text-based on we have today? I greatly disagree. HTTP/1.1 could use an update, but HTTP/2 was not the answer.

Only the framing is binary. The PDUs are actually still plain text and 95% (perhaps more) of the semantics of HTTP/1.1 have been retained. Just pointing it out because your comment makes it sound like HTTP/2 is completely binary. Also, how is HTTP/2 more bloated than HTTP/1.1? It simply adds a little framing; most of the bloat of HTTP/1.1 is retained. And as others have pointed out, HTTP/1.1 is hardly 'simple'. Someb…

> Just pointing it out because your comment makes it sound like HTTP/2 is completely binary

Functionally what's the difference? If I'm unable to read the entire message without a decoder, does it matter if I can read part of it?

> It simply adds a little framing;

I think yo forgot the whole reïnventing Layer-4 in Layer-7 thing. That is a travesty -- adding tons of complexity to solve a problem that it shouldn't be solving.

> We have nice tools like Wireshark these days which make it much easier for humans to read both binary and plain text protocols.

And the more tools _required_ to debug a problem, the harder it becomes to debug.

> spends something like 30% of its CPU time parsing/processing just the Date header because it's in plain text.

Plain-text is not a panacea, however I believe it preferable to a binary protocol for ease of debugging and hackability. If there are issues like the HTTP Date is causing trouble for many people, maybe we should look into how that could be made easier? A better format? Does the Date header even need to exist? (I actually don't think it does, along with Server, UA, and a couple others).

Additionally, I really wish that HTTP/2 would have actually attempted to solve problems faced by smaller HTTP users, and not force a behemoth of complexity (remember Layer 4 in Layer 7) on users who do not want that. I outline what I was hoping to be solved at https://github.com/jimktrains/http_ng.

Re: Hello HTTP/2, Goodbye SPDY

#166

Post by jimktrains2 » Tue, Feb 10, 2015, 1:54 PM UTC

runeks wrote: post #152

drderidder wrote: post #54

I got a copy of Paul-Henning Kamp's critique "HTTP/2.0 - The IETF is Phoning It In" off the ACM website before the link went dead. Here's a bit of what he said about it: "Some will expect a major update to the world’s most popular protocol to be a technical masterpiece and textbook example for future students of protocol design. Some will expect that a protocol designed during the Snowden revelations will improve the…

> This is almost triply ironic, because the major drags on HTTP are the cookies, which are such a major privacy problem, that the EU has legislated a notice requirement for them. Which, of course, is useless, since any browser supports turning off cookies. As an EU citizen, my experience of this regulation is simply that I have to click "OK" to accept cookies on all the EU sites I visit. I apologize if this comes off…

Which is why, as a tech community, we should have attempted to come up with a better solution. A session identifier controlled by the client (Say, just a UUID and can store no data from the server) and with the associated UI to cleaning "logout" or "reset" a session with a website, may have alleviated privacy concerns without breaking the functionality we originally were looking to add to HTTP.

Yes, this would not have been able to be rolled out to everyone immediately, but neither is any other addition to JS, HTTP, HTML, CSS, &c. We should help build the future, not simply accommodate the past all the time.

Re: Hello HTTP/2, Goodbye SPDY

#167

Post by ropiku » Tue, Feb 10, 2015, 2:42 PM UTC

xpose2000 wrote: post #55

Does anyone know if Cloudflare has plans to implement HTTP/2? RIght now they support SPDY. I found the answer from their blog: "Part of the service CloudFlare provides is being on top of the latest advances in Internet and web technologies. We've stayed on top of SPDY and will continue to roll out updates as the protocol evolves (and we'll support HTTP/2 just as soon as it is practical)."

Do you know if they support SPDY downstream too ?

Re: Hello HTTP/2, Goodbye SPDY

#168

Post by jorisw » Tue, Feb 10, 2015, 3:25 PM UTC

Kurtz79 wrote: post #164

runeks wrote: post #152

Earlier quoted context omitted.

> This is almost triply ironic, because the major drags on HTTP are the cookies, which are such a major privacy problem, that the EU has legislated a notice requirement for them. Which, of course, is useless, since any browser supports turning off cookies. As an EU citizen, my experience of this regulation is simply that I have to click "OK" to accept cookies on all the EU sites I visit. I apologize if this comes off…

My experience is the same, with an added facepalm everytime I see it. It is a EU thing then ? It appears or not depending on the origin ip address of the request ?

Yes, it is law in various EU countries that requires websites to ask permission to store cookies. However, now that the leglislators have seen the effect and have educated themselves some more, the law is already being effectively retracted, at least in my country (NL).

Re: Hello HTTP/2, Goodbye SPDY

#169

Post by bsdetector » Tue, Feb 10, 2015, 3:36 PM UTC

gsnedders wrote: post #163

bsdetector wrote: post #160

Earlier quoted context omitted.

At the time SPDY came out, Opera and Android Browser had pipelining on by default and Firefox was about to also default it on. They didn't only because of the promise of SPDY, not because pipelining "is busted". Pipelining works fine in almost all cases. And if you only enable pipelining to known-good servers over a non-MITM SSL connection -- exactly like SPDY does -- then there is absolutely no problem with it and i…

Firefox wasn't about to default it to being on (yes, there was work being done on it to see how workable it was, but there was no decision to ship it) — it's well-known that pipelining causes all kinds of bizarre breakage with badly behaved servers and proxies (and the latter are where the implementations are especially bad). Opera had enough problems with pretty crazy-complex heuristics as to when to enable pipelini…

> Determining what a known-good server is over SSL isn't that easy.

Just the opposite. Both Firefox and Chrome's discussion of pipelining claim that "unknown" MITM software is why they didn't turn on pipelining. Nobody knows what this software is (could be malware). But whatever this mystery software is can't look inside SSL, so pipelining in SSL was just as doable as inventing SPDY.

If Google hadn't pushed SPDY then pipelining was going to happen, and the unknown bad software would have been fixed or blacklisted. Android was using pipelining for years in Browser until Google replaced it with SPDY. Mobile Safari has been using pipelining since 2013 (probably why it wins the mobile page load time benchmarks). Pipelining works.

Yes, some endpoints could be buggy, for instance IIS 4 (in Windows NT 4) was blacklisted in Firefox. Introducing a new, more complicated protocol just because of 10 year old outdated software is not a great way to solve problems.

Re: Hello HTTP/2, Goodbye SPDY

#170

Post by patrickmcmanus » Tue, Feb 10, 2015, 3:57 PM UTC

dragonwriter wrote: post #101

hacst wrote: post #97

Earlier quoted context omitted.

The header compression in HTTP 2.0 isn't based on gzip or something like that. The CRIME attack pretty much killed those approaches dead. It's more akin to differential updates for header during the lifetime of the connection. So if you request a lot of files with fairly similar headers you'll effectively only have to transmit the bulk of the header once while the other request will efficiently re-use the previously…

> So to answer your question: Header compression as employed in HTTP 2.0 helps if you do many requests with similar headers on the same connection. In general, HTTP/2.0 seems to be about improving things if you do many requests over the same connection.

right. The other key fact is that request header compression is necessary to make parallelism work when interacting with tcp congestion control. Its critical.