HTTP 2.0(tools.ietf.org)
tools.ietf.org
HTTP 2.0
http://tools.ietf.org/html/draft-ietf-httpbis-http2-04
322 comments
Well this is clever:
" HTTP/2.0 enables a server to pre-emptively send (or "push") multiple associated resources to a client in response to a single request. This feature becomes particularly helpful when the server knows the client will need to have those resources available in order to fully process the originally requested resource. "
If someone asks for your HTML, might as well send them the CSS, JS, and images it is going to use. Would cut down on requests. Only thing more efficient than compression, is not having to ask in the first place.
" HTTP/2.0 enables a server to pre-emptively send (or "push") multiple associated resources to a client in response to a single request. This feature becomes particularly helpful when the server knows the client will need to have those resources available in order to fully process the originally requested resource. "
If someone asks for your HTML, might as well send them the CSS, JS, and images it is going to use. Would cut down on requests. Only thing more efficient than compression, is not having to ask in the first place.
I still feel like this is just being rammed through far far too fast. SPDY might well be the right way to go, but it's only been deployed for a small number of very large sites for a couple of years at this point. It was a foregone conclusion when the schedule was announced for http2.0 that it would be spdy, because only spdy has demonstrable value in production. There was no time for anyone to come up with or evaluate an alternative. But on the other hand, there hasn't been near enough time to demonstrate that spdy is good for the whole internet, which is what blessing it with the http protocol name implies.
And I just don't see why it should be rammed through. SPDY has a connection upgrade path, that afaik is largely unchanged for http2.0 anyways.
And I just don't see why it should be rammed through. SPDY has a connection upgrade path, that afaik is largely unchanged for http2.0 anyways.
You still can't self-sign certificates and rely on certificate pinning for transport security without domain verification. With all of the security concerns people have with governments logging all unencrypted internet traffic, I was hoping HTTP 2.0 would require or at least optionally allow self-signed cert TLS for every http: connection (with no UI indication to the user that they are secure) and require CA-signed cert TLS for https:
We're also still stuck with DEFLATE, which is vastly inferior to modern compression formats like LZMA.
We're also still stuck with DEFLATE, which is vastly inferior to modern compression formats like LZMA.
Going to binary seems kind of silly at this point.
HTML is text. Javascript is text. XML is text. JSON is text. SVG is text. CSS is text.
Is it really worth the complication to save a few bytes on HTTP headers when you're just going to shovel out inefficient text data in most cases anyway?
I don't understand why they're trying to shove this down everybody's throat as a new version of HTTP.
There are a ton of ports besides 80. The better thing to do, IMO, would be to make a new protocol on some other port and add it to their browsers.
HTML is text. Javascript is text. XML is text. JSON is text. SVG is text. CSS is text.
Is it really worth the complication to save a few bytes on HTTP headers when you're just going to shovel out inefficient text data in most cases anyway?
I don't understand why they're trying to shove this down everybody's throat as a new version of HTTP.
There are a ton of ports besides 80. The better thing to do, IMO, would be to make a new protocol on some other port and add it to their browsers.
This makes it easier for web application designers, but is less optimal for those publishing static pages, which are actually the mainstay of the web.
Further, it's less user-explorable, which further distances the web from access by the everyday tinkerer as opposed to the professional with lots of time to explore.
Further, it's less user-explorable, which further distances the web from access by the everyday tinkerer as opposed to the professional with lots of time to explore.
Is this a proposal to reimplement (badly) TCP inside of HTTP ? So we'll have a TCP stack running on top of a TCP stack ?
Those who don't learn history are doomed to repeat it.
I predict that this will lead to unexpected performance problems due to collisions in Tx window size between TCP windows and HTTP 2.0 frames.
Those who don't learn history are doomed to repeat it.
I predict that this will lead to unexpected performance problems due to collisions in Tx window size between TCP windows and HTTP 2.0 frames.
I really disliked the following part: A client MAY immediately send HTTP/2.0 frames to a server that is known to support HTTP/2.0, after the connection header. [..] Prior support for HTTP/2.0 is not a strong signal that a given server will support HTTP/2.0 for future connections. (Section 3.4)
That means, whenever you open a new TCP connection to a http2 server, you must start with HTTP/1.1 and perform the Upgrade negotiation anew.
Making the spec require HTTP2 support on all servers of a cluster if at least one server supports it would have been much better, performance-wise. The only reason I see why they kept it is transparent proxies (if your browser is using an explicit proxy, it should be able to figure out if the proxy supports HTTP2).
That means, whenever you open a new TCP connection to a http2 server, you must start with HTTP/1.1 and perform the Upgrade negotiation anew.
Making the spec require HTTP2 support on all servers of a cluster if at least one server supports it would have been much better, performance-wise. The only reason I see why they kept it is transparent proxies (if your browser is using an explicit proxy, it should be able to figure out if the proxy supports HTTP2).
Hmm... I have a few scripts that do something like:
header($_SERVER['SERVER_PROTOCOL'] . ' 400 Bad Request');
HTTP/2.0 should be SIP because of similarities and also integrated session management. Not some application layer binary protocol to spy on people even faster. Yeah baby :-)
Hope http 2.0 is the new ipv6 !
Totally superficial but why do I have to type http every time? Why can't it be h and hs (for https). Quicker to type.
Most of the complaints are around the ascii vs binary. Can we just make it accept both and move on?
Source code & issues tracker: https://github.com/http2/http2-spec
Wiki: http://tools.ietf.org/wg/httpbis/
Wiki: http://tools.ietf.org/wg/httpbis/
I understand the motivation to going to a binary protocol for a SPDY inspired HTTP 2.0 but I would have liked to see an ascii based protocol similar to what jgrahamc proposed last year [0]. I thought it was a much cleaner protocol to read and understand, and much more in tune with what the web is supposed to be. Why not keep the clever binary stuff separate in SPDY, endorse it though the IETF and keep HTTP ascii?
[0] http://blog.jgc.org/2012/12/speeding-up-http-with-minimal-pr...
[0] http://blog.jgc.org/2012/12/speeding-up-http-with-minimal-pr...
Congrats to Google for ruining the internet standards in an official way, without strong proofs of big significant improvements over the simpler past protocol.
Only implementations of the final, published RFC can identify
themselves as "HTTP/2.0". Until such an RFC exists, implementations
MUST NOT identify themselves using "HTTP/2.0".
[deleted]
Can anybody summarize the main differences between this and the older versions of HTTP?
At first glance, the spec appears to be re-implementing a TCP stack inside a TCP connection...
"PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n"
Ah, so every HTTP 2.0 connection has PRISM in it.
Ah, so every HTTP 2.0 connection has PRISM in it.
Given the close relationship between Google and the NSA, I suggest they are removed from the IETF until further notice. I would trust Microsoft more than the snake oil Google produces.
No surprise they've opted for a binary protocol rather than ASCII, anything to reduce transparency
No surprise they've opted for a binary protocol rather than ASCII, anything to reduce transparency
/sarcasm
What happened to simple protocols? Seriously, per-hop flow control (which works best with which of the dozen version of TCPv4 or TCPv6 flow control?)? TCPv4-like framing with weird limits (16383 bytes)? Keepalives/Ping? Truly ridiculous specialized compression for headers which ignores the role of HTTP proxies? QoS?
Why not just implement the whole protocol over a raw IP connection and stop pretending like we're operating in layer 4+? I get that multiplexing is difficult without flow control, but good lord does this thing look overdesigned for what few benefits it offers over HTTP/1.1.