Live data from Hacker News

Hello HTTP/2, Goodbye SPDY

blog.chromium.org

41–50 of 181 posts

Re: Hello HTTP/2, Goodbye SPDY

#41
post #19

Earlier quoted context omitted.

Agreed, Google did the right thing to remove Gears. My concern is because, overall, Google has a bad track record in this area: FileSystem is still enabled, WebSQL is still enabled, PNaCl is still enabled edit: and H.264 was never removed despite announcing the intent to do so.

websql is so much nicer then the key/val firefox insisted on :(

WebSQL is nicer to use, but requiring every browser to be bug-for-bug compatible with SQLite 3.0.17 (or whatever it was) forever and ever is not nice for browser developers.

Re: Hello HTTP/2, Goodbye SPDY

#42

Earlier quoted context omitted.

> I'm not ever supporting HTTP/2. Congrats? Want a cookie or something? Do you have an actual complaint with the spec or do you just want to be an old man yelling at a cloud?

My "actual" complaint is that it's not enough to be a major version and that it's a system that only benefits large corporations with data to pre-push, with no other benefits. You can think differently, of course, but after looking at this ( https://news.ycombinator.com/item?id=8824789 ) I reconsidered my previously positive view on it. (Also, I'd love a cookie)

So you'd be ok if they called it HTTP/1.2?

Snark aside, it's a standardized way of allowing different architectural patterns that can benefit use cases we haven't even seen yet. Yes, those architecture patterns currently benefit large corporations, but they're not being implemented at the expense of anything else. HTTP is a remarkably complete and flexible protocol.

What other benefits were you expecting to see that aren't already part of HTTP/1.1?

Re: Hello HTTP/2, Goodbye SPDY

#43
post #39

Earlier quoted context omitted.

I can point you to a benchmark that disagrees. http://www.guypo.com/not-as-spdy-as-you-thought/ . I promise you that I've considered the spec and its implications. Where are we now?

First comment: "This study is very flawed. Talking to a proxy by SPDY doesn't magically make the connection between that proxy and the original site use the SPDY protocol, everything was still going through HTTP at some point for the majority of these sites. Further, the exclusion of 3rd party content fails to consider how much of this would be 1st party in a think-SPDY-first architecture, where you know you'll reduc…

Sure. It illustrates how any benchmark can be flawed because it's tailored to the point it's trying to make. The author of that article thought this scenario was "more realistic." What is more realistic to him is not to other people.

And thus, benchmarks are unhelpful.

I care about feature sets and major improvements, not minor down-to-the-wire fixes. If this were called HTTP/1.2 or something I'd be less critical, but there are so many issues and flaws left unfixed, with unhelpful bikeshedding occurring over perceived "performance".

Re: Hello HTTP/2, Goodbye SPDY

#44
post #42

Earlier quoted context omitted.

My "actual" complaint is that it's not enough to be a major version and that it's a system that only benefits large corporations with data to pre-push, with no other benefits. You can think differently, of course, but after looking at this ( https://news.ycombinator.com/item?id=8824789 ) I reconsidered my previously positive view on it. (Also, I'd love a cookie)

So you'd be ok if they called it HTTP/1.2? Snark aside, it's a standardized way of allowing different architectural patterns that can benefit use cases we haven't even seen yet. Yes, those architecture patterns currently benefit large corporations, but they're not being implemented at the expense of anything else. HTTP is a remarkably complete and flexible protocol. What other benefits were you expecting to see that…

From https://news.ycombinator.com/item?id=8825001:

  * no more easy debugging on the wire
  * another TCP like implementation inside the HTTP protocol
  * tons of binary data rather than text
  * a whole slew of features that we don't really need but that please some corporate sponsor because their feature made it in

  * continuing, damaging and absurd lack of DNS and IPv6 considerations
    * most notably the omission of any discussion of endpoint resolution
Fixing anything related to DNS, DNSSEC, IPv6, or anything else would have made this closer to "HTTP/2."

And as I said in another thread: yes. Calling it HTTP/1.2 would actually have made me a little happier. This isn't the next new, big thing. This is a minor improvement, if not a minor regression.

Re: Hello HTTP/2, Goodbye SPDY

#45
post #31
post #26

Anybody aware of a good C++ server framework supporting most of HTTP/2, including websockets?

Facebook's proxygen has HTTP/2 support "in progress": https://github.com/facebook/proxygen

Yes, but I believe they don't support websockets yet. At least, searching their github for "websockets" gives only two broken links.

UPDATE: I noticed somebody wrote websocket support [1], but it didn't get merged yet with the master.

[1] https://github.com/kekekeks/proxygen

Re: Hello HTTP/2, Goodbye SPDY

#46
post #27

I'm not ever supporting HTTP/2. For something "monumental" enough to be called the whole second revision of HTTP, what have we really gained? A Google-backed "server push" mechanism and some minor efficiency additions? Add to that the fact that SPDY was pushed through as HTTP/2 because nothing else was ready. Please. Downvoters: although I don't usually do this, I'd ask you to enter into a discussion with me instead…

If that doesn't convince you to support HTTP/2, then nothing will: https://www.httpvshttps.com/ HTTP/1.1 is 5x-15x slower in this benchmark! These insane perf gains are possible only thanks to HTTP/2, specifically thanks to its support for multiplexing. Please read the spec and understand the technical implications before criticizing. On some unrelated note: I found this tidbit of humor in the RFC draft ( https://too…

Not really a fair benchmark. It's making tons of requests with tiny payloads, so that most browsers will hit a connection limit and requests will be queued up.

Heavily optimized pages like google.com use data urls or spritesheets for small images, and inline small css/javascript.

On the bright side, reducing the need to minimize request count will make our lives as developers a bit easier :-)

Re: Hello HTTP/2, Goodbye SPDY

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

Re: Hello HTTP/2, Goodbye SPDY

#48
post #39

Earlier quoted context omitted.

First comment: "This study is very flawed. Talking to a proxy by SPDY doesn't magically make the connection between that proxy and the original site use the SPDY protocol, everything was still going through HTTP at some point for the majority of these sites. Further, the exclusion of 3rd party content fails to consider how much of this would be 1st party in a think-SPDY-first architecture, where you know you'll reduc…

Sure. It illustrates how any benchmark can be flawed because it's tailored to the point it's trying to make. The author of that article thought this scenario was "more realistic." What is more realistic to him is not to other people. And thus, benchmarks are unhelpful. I care about feature sets and major improvements, not minor down-to-the-wire fixes. If this were called HTTP/1.2 or something I'd be less critical, bu…

so your only real issue is with the version number.

Re: Hello HTTP/2, Goodbye SPDY

#49
post #39

Earlier quoted context omitted.

First comment: "This study is very flawed. Talking to a proxy by SPDY doesn't magically make the connection between that proxy and the original site use the SPDY protocol, everything was still going through HTTP at some point for the majority of these sites. Further, the exclusion of 3rd party content fails to consider how much of this would be 1st party in a think-SPDY-first architecture, where you know you'll reduc…

Sure. It illustrates how any benchmark can be flawed because it's tailored to the point it's trying to make. The author of that article thought this scenario was "more realistic." What is more realistic to him is not to other people. And thus, benchmarks are unhelpful. I care about feature sets and major improvements, not minor down-to-the-wire fixes. If this were called HTTP/1.2 or something I'd be less critical, bu…

> And thus, benchmarks are unhelpful.

No, they are helpful! Especially real-world benchmarks. Sure you can cook up utterly flawed benchmarks (like the one you pointed to), but that doesn't mean all benchmarks are unhelpful. A good engineer knows which benchmarks matter, which don't. You don't seem to be able to do that.

> If this were called HTTP/1.2 ...

The mere fact you brought this up (no amount of backpedalling you may do after my comment on this) makes your criticism look even stupider. You should judge the spec based on its technical content, not based on whatever arbitrary version number was assigned to it. Talk about a bike-shed argument (http://en.wikipedia.org/wiki/Parkinson's_law_of_triviality)

Re: Hello HTTP/2, Goodbye SPDY

#50

I'm not ever supporting HTTP/2. For something "monumental" enough to be called the whole second revision of HTTP, what have we really gained? A Google-backed "server push" mechanism and some minor efficiency additions? Add to that the fact that SPDY was pushed through as HTTP/2 because nothing else was ready. Please. Downvoters: although I don't usually do this, I'd ask you to enter into a discussion with me instead…

This attitude is exactly how you make sure that nothing ever changes or improves. It is "the perfect is the enemy of the good" exemplified. HTTP/2 is a huge improvement over HTTP in many very important ways. True, it's not perfect, but guess what? 2 is not the last version number out there. We can switch to HTTP/2 now and fix the rest of the problems with HTTP/3. Moreover, it seems like we are collectively getting be…

I appreciate your optimism, but do realize that there isn't really a massive improvement unless you're Google. I don't see this as worthy of the "/2" suffix; Google might like it because it allows them to make their tech standard, but other than that it's unnecessary marketing.

HTTP has never been the bottleneck. I think IPv6 is excellent and a needed, massive improvement especially since IPv4 is no longer tenable. HTTP/1.1, however, still works quite well and keeps a larger feature set in some circumstances. It's less insane because it's not made by W3C or IETF or any other hugely bureaucratic group; however, that doesn't mean it's better either.

I can't wait for HTTP/3! Hopefully this time they won't rush it.

Post reply on HN