Live data from Hacker News

Hello HTTP/2, Goodbye SPDY

blog.chromium.org

151–160 of 181 posts

Re: Hello HTTP/2, Goodbye SPDY

#151
post #47

Unfortunately right now apache doesn't support HTTP/2 at all. There was a mod_spdy, but it's pretty much dead. Apache took it over from google some time ago, but since then nothing happened.

This is what happens when you let Google (or other big corporations) write internet-standards.

If it isn't community-driven, you can't expect it to be implemented in the places the big corp doesn't care for.

So in this case, Apache one of the major drivers for propelling the WWW may end up not supporting a "crucial" WWW-related standard, because the community was never invited.

If anyone still has any doubts why letting Google control internet-standards is bad, this is currently my best example.

Technically speaking, the internet is the result of what we come up with, when we all work together. Not working together will quickly end up as not working at all.

Re: Hello HTTP/2, Goodbye SPDY

#152

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 as a rant, but it really is annoying to constantly be presented with "This site uses cookies. Continue?" when I visit a site. :)

Re: Hello HTTP/2, Goodbye SPDY

#153
post #74

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…

Whatever PHK wants it to be, HTTP/2 is a great step forward from where we are today. Check this out: https://http2.golang.org/gophertiles This is going to make the web so much faster, particular on mobile devices.

>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

Re: Hello HTTP/2, Goodbye SPDY

#154
post #152

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…

Agreed, it is completely useless. I have never heard of anyone benefiting from this the slightest. A side effect could have been that people actually stopped and learned what cookies was, but as I've asked my non-technical friends, no one has bothered to do this. I can't say I blame them.

Re: Hello HTTP/2, Goodbye SPDY

#155
post #71

Earlier quoted context omitted.

That's so lame. It's so easy to set up a new website today, it's going to be a huge burden in the future. Some of us still make websites for fun, not as businesses. I guess I have to buy a cheap ssl certificate from some sleezy website every time I feel creative.

Or we're about to see a whole lot of market incentive to make it easier to set up a site under TLS, which may only happen with this kind of unilateral move.

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 already be hogging port 443, you need to read up on how SSL/TLS and how certificates work in order to correctly request one, and then you need to figure out how those bits and pieces from that process fits into the server-stack you have decided to run with, and then you need to setup all those extra things server-side, which may or may not involve learning quite a bit of Unixy or sysadminy-things.

Phew

And that was step 1. See the contrast? In the playful internet of past times and glory you would have your product/experiment be done by now. In your "secure" internet you're merely done bootstrapping.

Yes, if you already have that, or already know all that stuff, that might not stop you moving along. For the amateur, who still should be the most welcome of all people on the internet for it to keep evolving, that's a complete show-stopper.

He'll just say "fuck this shit" most likely decide that this is just too big a task to even bother starting.

Forcing SSL everywhere on everyone is bad for the internet. I don't need to do everything "securely", and I sure as hell don't intend to setup every single experiment I do securely. Make it too much of a hurdle, and maybe I'll just stop experimenting instead.

And then, if not the internet, its spirit dies.

Re: Hello HTTP/2, Goodbye SPDY

#156
post #71

Earlier quoted context omitted.

That's so lame. It's so easy to set up a new website today, it's going to be a huge burden in the future. Some of us still make websites for fun, not as businesses. I guess I have to buy a cheap ssl certificate from some sleezy website every time I feel creative.

You can still use HTTP/1.1.

So HTTP/2.0 was launched as the replacement for HTTP/1.1, but without support for one of the most commonly used features.

Is this a joke?

Re: Hello HTTP/2, Goodbye SPDY

#157
post #74

Earlier quoted context omitted.

Whatever PHK wants it to be, HTTP/2 is a great step forward from where we are today. Check this out: https://http2.golang.org/gophertiles This is going to make the web so much faster, particular on mobile devices.

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

Re: Hello HTTP/2, Goodbye SPDY

#158

Earlier quoted context omitted.

Or we're about to see a whole lot of market incentive to make it easier to set up a site under TLS, which may only happen with this kind of unilateral move.

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.

Re: Hello HTTP/2, Goodbye SPDY

#159
post #47

Unfortunately right now apache doesn't support HTTP/2 at all. There was a mod_spdy, but it's pretty much dead. Apache took it over from google some time ago, but since then nothing happened.

This is what happens when you let Google (or other big corporations) write internet-standards. If it isn't community-driven, you can't expect it to be implemented in the places the big corp doesn't care for. So in this case, Apache one of the major drivers for propelling the WWW may end up not supporting a "crucial" WWW-related standard, because the community was never invited. If anyone still has any doubts why lett…

I think the reality here is, this is what happens when you let companies fight over a standard in private.

What I saw on the HTTP/2 mailing lists was "We have a new standard." "It demands SSL, but we don't want that." Then, SPDY is everywhere, let's use that.

Shortly after it was "Omg, we can't call it spdy, because then Microsoft's interests will be left behind and Google will have won. Let's abandon the mandatory SSL requirement and rename SPDY to HTTP2..."

I feel like we've all lost here.

We implemented SPDY at Twitter - the savings were fantastic and the browser performance, amazing. Google and FB did the same. It's nearly like, 800M users said it was great, can we move on now?

Re: Hello HTTP/2, Goodbye SPDY

#160
post #148

Earlier quoted context omitted.

> These insane perf gains are possible only thanks to HTTP/2, specifically thanks to its support for multiplexing. What's sad about this is that if you load this site with pipelining enabled you get the same speed benefits as with HTTP/2 or SPDY, but Google would never know this, since they never tested SPDY against pipelining. > ENHANCE_YOUR_CALM (0xb): > Please read the spec and understand the technical implication…

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 it performs similarly to SPDY. But I have no doubt you will continue spreading the party line from your employer, who couldn't be bothered to even test this.

Post reply on HN