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

Hello HTTP/2, Goodbye SPDY

blog.chromium.org

Post reply on HN
Print view View original

171–180 of 181 posts

Re: Hello HTTP/2, Goodbye SPDY

#171

Post by tracker1 »

jimktrains2 wrote: post #166
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…

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

Considering (relative to now) cookies were added really early on... it would have made sense to have a user/browser token that was only available to a single site, with a reset option.

Another thing that's a little irksome is that nobody uses http auth, because there's no easy logout option.

I will say I do like parts of http/2 being there... I think that dnssec + tls should have been part of the official mix. At the very least CA pricing has fallen into a reasonable range (about $10/month) for wildcard certs. Another thing that took too long is SNI.

Overall though, I think people have gotten pretty spoiled when it comes to technology (myself included)... OMG it takes a whole second and a half between clicking login and being able to see my bank statement. I remember when it was 15-seconds... I think everyone should experience a modem ANSI interface at 9600bps... (not just because I still like BBSes and ANSI art).

Re: Hello HTTP/2, Goodbye SPDY

#172

Post by gsnedders »

bsdetector wrote: post #169
gsnedders wrote: post #163

Earlier quoted context omitted.

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…

The endpoints can be (and often are, in absolute terms) buggy. TLS stops bad proxies from breaking stuff, but it doesn't stop endpoints from breaking stuff.

Re: Hello HTTP/2, Goodbye SPDY

#173

Post by bsdetector »

enneff wrote: post #157
anon1385 wrote: post #153

Earlier quoted context omitted.

>This is going to make the web so much faster, particular on mobile devices. The performance benefits are overblown: https://news.ycombinator.com/item?id=8890839

HTTP pipelining doesn't work in practice, so comparing it to SPDY or HTTP/2 is a waste of time.

Every Android phone was using pipelining until Google removed it. Every iOS device uses pipelining since iOS 5.

These phones work in practice.

Re: Hello HTTP/2, Goodbye SPDY

#174

Post by dragonwriter »

dark_photon wrote: post #158
josteink wrote: post #155

Earlier quoted context omitted.

In the beginning of the internet, when it flourished and bloomed, it did so because it was open to tinkering, hacking and fun ! You could 1. set up a server, and just 2. enter the IP, and you had a website to hack on! Now... You need to not only do that, you need to understand DNS and then pay a registrar to get a domain, you probably need to get hosting, because your router's secure ISP-side admin-interface may alre…

You are misunderstanding. The requirement for CA-issued certificates and most of the other things you are ranting about will still be only for HTTPS, which will still be optional. HTTP URIs in HTTP/2 will only need self-signed certificates which can be generated automatically by the server. Once servers get good support for it will not be any harder than HTTP/1.1.

> HTTP URIs in HTTP/2 will only need self-signed certificates which can be generated automatically by the server.

Where in the spec is there anything that HTTP URIs in HTTP/2 require any kind of certificate? Anyhow, I think its moot because all of the major browser vendors that have committed to HTTP/2 support have also announced they will support it only for HTTPS URIs, so what HTTP URIs require really only matters for non-browser HTTP-based applications that plan to use HTTP/2.

Re: Hello HTTP/2, Goodbye SPDY

#175

Post by dark_photon »

dragonwriter wrote: post #174
dark_photon wrote: post #158

Earlier quoted context omitted.

You are misunderstanding. The requirement for CA-issued certificates and most of the other things you are ranting about will still be only for HTTPS, which will still be optional. HTTP URIs in HTTP/2 will only need self-signed certificates which can be generated automatically by the server. Once servers get good support for it will not be any harder than HTTP/1.1.

> HTTP URIs in HTTP/2 will only need self-signed certificates which can be generated automatically by the server. Where in the spec is there anything that HTTP URIs in HTTP/2 require any kind of certificate? Anyhow, I think its moot because all of the major browser vendors that have committed to HTTP/2 support have also announced they will support it only for HTTPS URIs, so what HTTP URIs require really only matters…

> they will support it only for HTTPS URIs

No. They may do that now but the intention is to support HTTP URIs that force TLS but allow self-signed certificates.

See https://wiki.mozilla.org/Networking/http2

"There is a separate, more experimental, build available that supports HTTP/2 draft-12 for http:// URIs using Alternate-Services (-01) and the "h2-12" profile. Sometimes this is known as opportunistic encryption. This allows HTTP/2 over TLS for http:// URIs in some cases without verification of the SSL certificate. It also allows spdy/3 and spdy/3.1 for http:// URIs using the same mechanism. "

Re: Hello HTTP/2, Goodbye SPDY

#177

Post by jimktrains2 »

tracker1 wrote: post #171
jimktrains2 wrote: post #166

Earlier quoted context omitted.

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

Considering (relative to now) cookies were added really early on... it would have made sense to have a user/browser token that was only available to a single site, with a reset option. Another thing that's a little irksome is that nobody uses http auth, because there's no easy logout option. I will say I do like parts of http/2 being there... I think that dnssec + tls should have been part of the official mix. At the…

I 100% agree with you on the auth part. Mutual auth via something like SRP built into the browser would be a huge boon to building web sites that don't have to handle the plain-text password. Some nice chrome on that, or even an interface with HTML ( or something) would be super nice.

> OMG it takes a whole second and a half between clicking login and being able to see my bank statement. I remember when it was 15-seconds

What's worse is that people seem to get offended when you say "I have a crappy computer and a crappy connection, this is too bloated". I actually started running noscript soley to block analytics and ads that causing page rendering to delay for 10+s. I had the page. It was all there, but the browser had to wait for all resources before it'd do a full render. All of that immediately stopped with noscript.

Re: Hello HTTP/2, Goodbye SPDY

#178

Post by Apofis »

js4all wrote: post #143
Apofis wrote: post #118

Earlier quoted context omitted.

What about SSL Termination? Would it still work if I terminate?

In the described setup, HAProxy is doing SSL termination. See the gist for the cert and crypto parameters. This is getting a A+ from ssllabs.

Thank you!

Re: Hello HTTP/2, Goodbye SPDY

#180

Post by dragonwriter »

dark_photon wrote: post #175
dragonwriter wrote: post #174

Earlier quoted context omitted.

> HTTP URIs in HTTP/2 will only need self-signed certificates which can be generated automatically by the server. Where in the spec is there anything that HTTP URIs in HTTP/2 require any kind of certificate? Anyhow, I think its moot because all of the major browser vendors that have committed to HTTP/2 support have also announced they will support it only for HTTPS URIs, so what HTTP URIs require really only matters…

> they will support it only for HTTPS URIs No. They may do that now but the intention is to support HTTP URIs that force TLS but allow self-signed certificates. See https://wiki.mozilla.org/Networking/http2 "There is a separate, more experimental, build available that supports HTTP/2 draft-12 for http:// URIs using Alternate-Services (-01) and the "h2-12" profile. Sometimes this is known as opportunistic encryption.…

I wasn't familiar with that, but that approach for HTTP URIs doesn't appear to be a spec requirement. Is there any indication that other browser vendors are going to follow that approach with HTTP URIs?
Post reply on HN