News for hackers. Stuff that matters.
Re:HTTP/2.0 Initial Draft Released by judofyr on Tuesday July 30, 2013 @04:38AM (#6125894)
> Another new concept is the ability for either side to push data over an established connection. While the concept itself is hardly revolutionary — this is after all how TCP itself functions – bringing this capability to the widespread HTTP world will be no small improvement and may help marry the simplicity of an HTTP API with the fully-duplexed world of TCP. While this is also useful for a server-to-server internal APIs, this functionality will provide an alternative to web sockets, long polling, or simply repeated requests back to the server – the traditional three ways to emulate a server pushing live data in the web world.

As far as I know, this is not true. Server Push is only for the server and can only be done as a response to a request. It's not a WebSocket alternative.

Server Push means that when a client sends a request (GET /index.html), the server can respond with responses for multiple resources (e.g. /index.html, /style.css and /app.js can be sent). This means the client doesn't have to explicitly GET those resources which saves bandwidth and latency.

Re:HTTP/2.0 Initial Draft Released by ablankst on Tuesday July 30, 2013 @05:16AM (#6125985)
If you check out the draft (http://tools.ietf.org/html/draft-ietf-httpbis-http2-04), it looks like either the client or the server is able to initiate and send data along the HTTP/2.0 streams.

And in Section 2.2:

>HTTP/2.0 provides the ability to multiplex multiple HTTP requests and responses onto a single connection. Multiple requests or responses can be sent concurrently on a connection using streams (Section 5).

This requires supporting client-initiated requests over an established connection.

Re:HTTP/2.0 Initial Draft Released by jbverschoor on Tuesday July 30, 2013 @04:57AM (#6125940)
If that's the case, push is a bad name. Besides that, isn't this where multipart responses should come into play?