Anybody know when nginx will support it?
Hello HTTP/2, Goodbye SPDY
21–30 of 181 posts
Re: Hello HTTP/2, Goodbye SPDY
#22Earlier quoted context omitted.
To be fair Google did happily kill Gears when HTML5 became a viable [early draft] standard.
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.
Not to mention not removing H.264 after promising to do so.
Re: Hello HTTP/2, Goodbye SPDY
#23Looking 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 )
Maybe you could share a scrubbed config?
Re: Hello HTTP/2, Goodbye SPDY
#24I'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 of just hitting the down arrow. Do you honestly think my discussion is worth being silenced?
Re: Hello HTTP/2, Goodbye SPDY
#25Earlier quoted context omitted.
To be fair Google did happily kill Gears when HTML5 became a viable [early draft] standard.
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 :(
Re: Hello HTTP/2, Goodbye SPDY
#26Anybody aware of a good C++ server framework supporting most of HTTP/2, including websockets?
Re: Hello HTTP/2, Goodbye SPDY
#27I'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://tools.ietf.org/html/draft-ietf-httpbis-http2-16):
ENHANCE_YOUR_CALM (0xb): The endpoint detected that its peer is
exhibiting a behavior that might be generating excessive load.Re: Hello HTTP/2, Goodbye SPDY
#28Earlier quoted context omitted.
To be fair Google did happily kill Gears when HTML5 became a viable [early draft] standard.
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.
> PNaCl is still enabled
Eh? What is the spec competitor to PNaCl? asm.js is a cute trick but it still lacks threads which is easily one of the biggest features of PNaCl. So what actual viable alternatives are there to PNaCl?
Re: Hello HTTP/2, Goodbye SPDY
#29I'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…
> 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?
Re: Hello HTTP/2, Goodbye SPDY
#30I'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…
The only explanation for this nonsense phaenomenon seems to be that HTTPS ports are less used generally, which isn't an argument in favor of HTTPS.