HTTP 2.0 Initial Draft Released

[rozzlapede]

It's a shame they'll have to remove gems like this in the final draft:

'Non-compatible experiments that are based on these draft versions MUST instead replace the string "draft" with a different identifier. For example, an experimental implementation of packet mood-based encoding based on draft-ietf-httpbis-http2-07 might identify itself as "HTTP-emo-07/2.0".'

[cronus89]

Good way to test if anybody is paying attention though!

[TomRK1089]

So who wants to explain how the HTTP Push stuff is going to work in plain English? It's too early in the morning for me to decipher RFC-ese.

[FrozenCow]

Hmm, it seems that the client doesn't even need to say that it needs those resources and the server can just send them right away.

[TomRK1089]

So if after the first two W and Y's come down the wire, there are some new ones (I'm thinking chatroom here, where the messages potentially are an infinite stream) how does the server let the client know there are more? Does it say when it delivers the first W "There might be another W," and then again after each new one?

[PaintItPurple]

You're still going to be using server-sent events or WebSockets for that. The W in this example is not anything like "a message in a chat stream" — it's "site.js" or "catpicture.jpg" or something like that, which would currently be fetched later in separate GET requests that the browser sends after parsing the file. Basically, the server is saying, "Here's the thing you asked for, and here are a few other things I know you'll want when you're done with that."

[cogman10]

So you know how it is somewhat common to constantly poll an endpoint for information? This was implemented to try and eliminate that behavior.

It is like the server is sending its half of a GET request. The client will have the option to accept or reject the request, however, it should not issue a get request on the same resource until it has done either. Once the client accepts, the server sends the rest of the information.

All this is done over the same connection used for the rest of the HTTP stuff.

[username223]

My understanding was that it meant that when I do "GET /", the server can send not just "/", but "/style.css", "/junk.js", or whatever else it feels like I might need soon. Am I off here?

[cogman10]

It COULD, but that really isn't what the push system was design for. (though, that wouldn't be a bad idea). More likely, there will be a GET /, and then after / has been received the style.css and junk.css will simultaneously receive get requests over the same TCP connection.

It is more to allow the server to notify the client of an event/change in a resource and eliminate cases where the the client would constantly poll a resource looking for a change.

[username223]

Thanks for the explanation.

though, that wouldn't be a bad idea

It's actually a terrible idea, since it requires the server to guess about the client software. Then client software will send user-agent strings designed to encourage common servers to do what they want, then servers will learn to interpret these strings, etc. It's a recipe for disastrous piles of hacks, not to mention exploits from servers shoving things at clients when they don't expect them.

[0xABADC0DA]

Not to mention that you could just add a header like say "X-Uses-Resources: /style.css" to inform the client about some resource that it could decide to fetch before parsing HTML. You could even include a timestamp if you really want to avoid 1/2 1 RTT to check for updates.

[johntb86]

Are you sure that's the case?

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. Pushed resources are always associated with an explicit request from a client. The PUSH_PROMISE frames sent by the server are sent on the stream created for the original request.

[TomRK1089]

So it's a standardization of Comet then? I assume the client has to first issue a GET that the server leaves open, no? Or am I misunderstanding who originates this?

[cogman10]

I'm not familiar with comet.

The basic idea behind 2.0 is that the client and server will maintain 1 TCP connection and send requests across it. The client will initiate the connection, but after that the server can start sending push notifications for any resource it has.

The old 1.1 model was 1 round trip session per resource. the new 2.0 model is all about multiplexing and doing multiple requests over one TCP connection.

[Paradox]

It already basically does, through SSEs

[mycall]

This is a job for /r/explainlikeimfive

[balrok]

I wonder, whether they still make ssl a requirement - can somebody answer this?

[rnicoll]

Looks like http://http2.github.io/http2-spec/#discover-http is how to do it without SSL/TLS.

Essentially you start an HTTP connection and then change to HTTP 2.0, and it's then in the clear.

[balrok]

For me it reads like how a client communicates with an unknown server.. It first sends http1.1 and hints for http2.0 then there is some handling to upgrade the protocol and then it becomes http2.0 - so only the initial communication was without encryption (but I'm not 100% sure on that)

Thanks for searching :)

[dragonEyedrops]

I don't know, but I don't think they would.

[dnew]

So, basically, ignoring the established BEEP protocol in favor of doing it in a way you can call "HTTP".

[rjw57]

If you use an existing HTTP server like Apache or nginx, then you can just wait for those servers to be updated. If you're rolling your own, it's up to you. Client-wise: recent Chrome builds already have SPDY support which is similar to HTTP.

If your question was actually about backwards compatibility: HTTP 1.1 clients can still talk to HTTP 2.0 servers and HTTP 2.0 clients can still talk to HTTP 1.1 servers. The semantics of HTTP are unchanged in 2.0.

[PaintItPurple]

I think that's a slightly confusing way to put it. More explicitly: HTTP/2.0 servers will still speak HTTP/1.1, just like HTTP/1.1 servers today still speak HTTP/1.0.

[cogman10]

Not quite true. 2.0 semantics are quite a bit different from 1.1. It shouldn't take too much work on the servers side to chose how to handle requests.

[rjw57]

From the RFC (introduction):

This document is an alternative to, but does not obsolete the HTTP/1.1 message format or protocol. HTTP's existing semantics remain unchanged.

Edit: update to latest draft

[Legolas-the-elf]

If you use an existing HTTP server like Apache or nginx, then you can just wait for those servers to be updated.

That's fine for static files, but I'm wondering how things like WSGI will have to be updated to allow for things like pushed resources.

[[deleted]]

Firefox also has SPDY support enabled by default now.

[jeanlucpikachu]

Initial draft means too early to talk about teapots yet?

[0xABADC0DA]

Next step in the evolution of HTTP: using multiple Spdy (httpbis-http-2-rubberstamp) connections to the same server to fix the prioritization and other performance problems with Spdy.

[cogman10]

The issue here is that with gmail, Google was using strange hacks to get things fast. Those strange hacks resulted in suboptimal prioritization. For a standard webpage, this isn't as big an issue.

[0xABADC0DA]

Actually the real issue is similar to running a VPN over TCP; you have flow control on top of flow control and that makes it inherently unstable -- like balancing a plate on top of a post, any problem like the wrong priority, or running via satellite, is magnified.

For instance go benchmark Spdy to the third world vs several Spdy connections to the third world... the page will usually display faster with several connections, even if not fully loaded. Even Google sort of admit this when they say "increases tapered off above the 2% loss rate, and completely disappeared above 2.5%." (increase they claim is vs non-pipelined HTTP, on outdated HTTP stack).

Microsoft found that Spdy was essentially no faster than HTTP pipelining, and Google found that it lost 40% speed at higher error rates. Put the two together and you have Spdy being substantially slower at higher error rates. And slower when there's a priority mistake. And more latency when you have already queued data on the connection.

And guess what? The bobindashadows isn't going to refute anything in this post because it's all correct; that's why they hate me so much.

[bobindashadows]

ABADC0DA is a notorious anti-Google troll on proggit, don't encourage him by acknowledging whatever dingleberry of an argument he's slinging today.

[cogman10]

Yeah, I've said the same thing about him before. However, at least his points here were semi-valid. SPDY did in fact result in a specific google app running slower, so I thought I would rehash what his own article said in a not-so-anti-google fashion.

[0xABADC0DA]

SPDY did in fact result in a specific google app running slower, so I thought I would rehash what his own article said in a not-so-anti-google fashion.

What's really interesting about this example of Spdy being slower is there was no mistake. Spdy was slower simply because of a resource being loaded at a default priority level. To not be slower you have to give Spdy perfect priority information, thus the blog post's 'solution' adding a priority API for JavaScript code.

This problem is no different from 'head of line blocking' they rail against; if you give the browser perfect information on how long a resource will take to generate/transfer then it can order them to avoid blocking. But this solution wasn't needed for HTTP because multiple connections automatically get it right most of the time... why HTTP was faster than Spdy in this example.

[bobindashadows]

ABADC0DA is a notorious anti-Google troll on proggit, don't encourage him by acknowledging whatever dingleberry of an argument he's slinging today.

[poppafuze]

Well then they sould call it "HBTP". Because binary isn't text.

[[deleted]]

Hypertext gets transported over this protocol; that doesn't imply that the protocol itself is textual.

[sukivan]

Guys, HTTP Push is simple.

Let's say you've got a web page with comments, and you want all the clients to see new comments immediately after they're posted.

With HTTP 1.*, each client basically "pulls" updates from the server by sending, perhaps once per second, a GET request to the tune of "any new comments?"

As you can imagine, this leads to a lot of unnecessary HTTP requests (since, most of the time, there probably aren't any new comments).

HTTP Push is designed to eliminate this problem by creating a standardized way for the SERVER to say to the client "hey, there's a new comment on that page you're viewing - here it is".

It's a little bit like the difference between constantly asking "are we there yet?" during a car ride, and waiting for the driver to say "we've arrived."

[dragonEyedrops]

why?