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

111–120 of 181 posts

Re: Hello HTTP/2, Goodbye SPDY

#111

Post by enneff »

venaoy wrote: post #84
striking wrote: post #72

Earlier quoted context omitted.

Okay. Fair enough. I concede that efficiency is important and that SPDY / HTTP/2 can improve upon it. But I don't believe that this is worth the hype because the exposed featureset is otherwise tiny. Efficiency is cool, yes, but I'm personally waiting until HTTP/3 fixes the other wrong things with the Internet before I implement anything. I think the amount of effort that goes into this is not worth the result. Why i…

> Okay. Fair enough. I concede that efficiency is important and that SPDY / HTTP/2 can improve upon it. Great, I appreciate you recognize this. > Why include tons of small resources on your page if they're not necessary? But it _is_ necessary. In every single of the examples I gave in my reply to dlubarov, it is necessary: - There are 100+ small images, icons, etc and all are displayed on the nytimes.com homepage. -…

It's not just web _pages_, either. Many people spend their days working in web applications, which HTTP/2 helps tremendously.

Re: Hello HTTP/2, Goodbye SPDY

#112

Post by drawkbox »

totony wrote: post #109
drawkbox wrote: post #88

Earlier quoted context omitted.

Did you close that tag in that textarea from some third party content? If not you're whole view is broken. It was a layer or hopeful standardization that was too hopeful and counted on implementers too much to be exact. It was a nice attempt but was quickly retracted to go to HTML5. I guess the same thing applies to HTTP/2, sometimes you have to dumb/simplify it down a little, the smartest way that relies on implemen…

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.

It was better, from an engineering aspect it should have been better and the world would have more precision and validity/verification on content.

But from an interoperability aspect (relying on implementations) the market didn't think it was better or we'd be using it still. HTML5 won because it was simple and met many needs demanded by the market.

The simple standards that provide more benefits, but most importantly are highly focused on interoperability and simplicity, win, always, even if they seem subpar from an exactness standpoint.

At one point in time SOAP had the same religious hype surrounding it that HTTP/2 seems to have. But sometimes you have to take a step to realize you are slightly off path according to the market, not what you might want to design and what should win but what happens with interoperability in the market. HTTP/2 and XHTML type standards are steps, to something better but are too top down or ivory tower eventhough they have lots of awesome and needed features.

Re: Hello HTTP/2, Goodbye SPDY

#114

Post by bsdetector »

mrb wrote: post #27
striking wrote: post #24

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…

> 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 implications before criticizing.

Please understand that -- technically -- this protocol is an embarrassment to the profession and to those involved in designing it.

Re: Hello HTTP/2, Goodbye SPDY

#116

Post by drawkbox »

HTTP/2 might have version 2 syndrome.

Another better way would have been keep SPDY, as there is usefulness there, separate and then on HTTP/2, to incrementally get there, and use an iteration of something like AS2/EDIINT (https://tools.ietf.org/html/rfc4130) which does encryption, compression and digital signatures on top of existing HTTP (HTTPS is usable as current but not required as it uses best compression/encryption currently available that the server supports). This standard still adheres to everything HTTP and hypertext transfer based and does not become a binary file format but relies on baked in MIME.

An iteration of that would have been better for interoperability, secure and fast. I have implemented it directly previously from RFC for an EDI product and it is used for sending all financial EDI/documents for all of the largest companies in the world Wal-mart, Target, DoD as well as most small and medium businesses with inventory. There are even existing interoperability testing centers setup for testing out and certifying products that do this so that the standard works for all vendors and customers. An iteration of this would have fit in as easily and been more flexible on the secure, compression and encryption side, and all over HTTP if you want as it encrypts the body.

Re: Hello HTTP/2, Goodbye SPDY

#117

Post by totony »

drawkbox wrote: post #112
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.

It was better, from an engineering aspect it should have been better and the world would have more precision and validity/verification on content. But from an interoperability aspect (relying on implementations) the market didn't think it was better or we'd be using it still. HTML5 won because it was simple and met many needs demanded by the market. The simple standards that provide more benefits, but most importantl…

HTML5 is a mix of XHTML and HTML4, but with new features. Its syntax ressemble more XHTML than HTML and as thus it is more XML compliant, although you can ignore strict syntax [0]. HTML5 is both XHTML and HTML4 alike, so it is no surprise that is has taken over the market.

Note that I don't especially like HTTP/2 and believe that a hack like SPDY should not make it to a standard. More time and care should be made to make a central protocol like HTTP (central in that it is used alot).

[0] Source: http://www.techrepublic.com/blog/10-things/10-things-you-sho...

>Instead, the HTML5 spec is written so that you can write HTML5 with strict XML syntax and it will work

Re: Hello HTTP/2, Goodbye SPDY

#118

Post by Apofis »

js4all wrote: post #17
anderspetersson wrote: post #5

Looking forward to when HAProxy support for HTTP/2 lands since they refused to implement SPDY support. Here's a list of common servers support for SPDY/HTTP2: https://istlsfastyet.com/#server-performance

Current HAProxy already supports the handshake of SPDY/HTTP2 via NPN and ALPN. You have to route to proper backends. You also need to provide a HTTP/1.1 fallback implementation for incapable clients. Once setup that works very well. I am using it for our blog ( https://blog.cloudno.de )

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

Re: Hello HTTP/2, Goodbye SPDY

#119

Post by jsmeaton »

js4all wrote: post #35
newman314 wrote: post #23

Earlier quoted context omitted.

Maybe you could share a scrubbed config?

Sure, here is a gist: https://gist.github.com/dvbportal/cccccbbf6163cfbbbce6 The frontend definition advertises spdy and http/1.1 protocols via npn. (this should be now ALPN, HAProxy supports it) The ssl_fc_npn ACL routes to the SSL-teminated traffic to the appropriate backends. Nginx is configured to serve two backends with one port for each protocol. There can be multiple instances with round robin, if necessary. T…

Thanks for sharing. Can the SPDY frontend only be tcp based though, not http? The reason I ask is because my setup does all the routing (path and subdomain based) with http frontends.

Re: Hello HTTP/2, Goodbye SPDY

#120

Post by MichaelGG »

jimktrains2 wrote: post #106
enneff wrote: 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.

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

I wonder if anyone complaining about binary formats has ever written a high performance parser.

Particularly, HTTP's text format, is a mess. You can continue headers from one line to another. You can embed comments into header values. Seriously. Comments. In a protocol's messages. It's moronic and indefensible. Why anyone would prefer that is probably them thinking that text equals easy to implement or something like that.

Post reply on HN