Subject: I-D Action: draft-ietf-httpbis-http2-01.txt

From: [email-masked]
Date: Mon, 21 Jan 2013 15:36:17 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Hypertext Transfer Protocol Bis Working Group of the IETF.

	Title           : Hypertext Transfer Protocol version 2.0
	Author(s)       : Mike Belshe
                          Roberto Peon
                          Martin Thomson
                          Alexey Melnikov
	Filename        : draft-ietf-httpbis-http2-01.txt
	Pages           : 50
	Date            : 2013-01-21

Abstract:
   This document describes an optimised expression of the semantics of
   the HTTP protocol.  The HTTP/2.0 encapsulation enables more efficient
   transfer of resources over HTTP by providing compressed headers,
   simultaneous requests, and unsolicited push of resources from server
   to client.

   This document is an alternative to, but does not obsolete
   RFC{http-p1}.  The HTTP protocol semantics described in RFC{http-
   p2..p7} are unmodified.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-httpbis-http2

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-httpbis-http2-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-httpbis-http2-01

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Frédéric Kayser <[email-masked]>
Date: Tue, 22 Jan 2013 02:35:13 +0100

Hello,
is this the mechanism clients should use to stop receiving pushed resources they already have in their local cache?
How are servers supposed to guess what to push or not? Is it be based on modification date, could the clients send some hints?

Frédéric

> 4.3.2.  Client implementation
> 
>    When fetching a resource the client has 3 possibilities:
> 
>       the resource is not being pushed
> 
>       the resource is being pushed, but the data has not yet arrived
> 
>       the resource is being pushed, and the data has started to arrive
> 
>    When a SYN_STREAM and HEADERS frame which contains an Associated-To-
>    Stream-ID is received, the client must not issue GET requests for the
>    resource in the pushed stream, and instead wait for the pushed stream
>    to arrive.
> 
> [...]
> 
>    To cancel individual server push streams, the client can issue a
>    stream error (Section 3.4.2) with error code CANCEL.  Upon receipt,
>    the server MUST stop sending on this stream immediately (this is an
>    Abrupt termination).

---

From: William Chan (陈智昌) <[email-masked]>
Date: Mon, 21 Jan 2013 18:23:04 -0800

Yes, the text at the bottom of your email is the mechanism that should
be used. It's possible that we could use some other mechanism to
convey the client cache in some way. There are many issues with it of
course.

Note that web developers are already pushing resources. It's called
resource inlining
(https://developers.google.com/speed/docs/pss/InlineSmallResources).
These resources do not have their own URLs, are usually inlined into
uncacheable documents, and thus are rarely cached at all. Using server
push will enable them to have their own URLs and be cached by the
client if that makes sense.

Remember, once you issue a request to a server, the server can send
you anything in return. It's in our interest to provide them better
facilities for sending responses, or they will hack around it in less
optimal ways.

---

From: Roberto Peon <[email-masked]>
Date: Mon, 21 Jan 2013 18:28:34 -0800

Push is simply better inlining, with prioritization and cancellation.

So, if you don't want a push, you'd cancel the stream, wasting at worst one
BDP worth of bandwidth, and at best near zero (since the push is announced
while the main resource is loading).

Note that if server push is disabled, then servers will inline resources
which is strictly worse as it is impossible to prioritize or cancel (or
cache) such, leading to *increased * bandwidth usage and latency.

-=R
On Jan 21, 2013 5:38 PM, "Frédéric Kayser" <[email-masked]> wrote:

> Hello,
> is this the mechanism clients should use to stop receiving pushed
> resources they already have in their local cache?
> How are servers supposed to guess what to push or not? Is it be based on
> modification date, could the clients send some hints?
>
> Frédéric
>

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 22 Jan 2013 14:35:13 +1100

I'd be interesting to hear what people running robots, etc. have to think about this.

Also, it'd be REALLY nice to think about about what this means for responsive design; e.g., if I'm a mobile, I don't need the desktop stylesheet, and maybe not some of those images too. So, how does that work in a push world?

Personally -- the most immediate problem I have with this is figuring out how to show push in REDbot :-/

Cheers,

On 22/01/2013, at 1:28 PM, Roberto Peon <[email-masked]> wrote:

> So, if you don't want a push, you'd cancel the stream, wasting at worst one BDP worth of bandwidth, and at best near zero (since the push is announced while the main resource is loading).
> 
> Note that if server push is disabled, then servers will inline resources which is strictly worse as it is impossible to prioritize or cancel (or cache) such, leading to *increased * bandwidth usage and latency.
> 
> -=R
> 

--
Mark Nottingham   http://www.mnot.net/

---

From: Roberto Peon <[email-masked]>
Date: Mon, 21 Jan 2013 20:01:40 -0800

On Mon, Jan 21, 2013 at 7:35 PM, Mark Nottingham <[email-masked]> wrote:

> Also, it'd be REALLY nice to think about about what this means for
> responsive design; e.g., if I'm a mobile, I don't need the desktop
> stylesheet, and maybe not some of those images too. So, how does that work
> in a push world?
>

The same way one would in a non-push world-- determine if it is mobile and
serve the most appropriate content... :)
-=R

> > So, if you don't want a push, you'd cancel the stream, wasting at worst
> one BDP worth of bandwidth, and at best near zero (since the push is
> announced while the main resource is loading).
> >

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 22 Jan 2013 15:06:18 +1100

On 22/01/2013, at 3:01 PM, Roberto Peon <[email-masked]> wrote:

> The same way one would in a non-push world-- determine if it is mobile and serve the most appropriate content... :)

Yes and no. Today, you have the option of doing it server-side *or* client-side. When the server is pushing, all the decisions are made server-side. That means, for example, that it'll be potentially more difficult to server a responsive site that's completely static.

---

From: Ilya Grigorik <[email-masked]>
Date: Mon, 21 Jan 2013 20:20:45 -0800

> stylesheet, and maybe not some of those images too. So, how does that work

I think these are mostly orthogonal. While its a good exercise to think
about this, I don't think this needs to be an explicit goal for HTTP 2.0.
The HTML5 spec specifically says that the resources should be downloaded,
even if the media-query breakpoint does not match (ex, print stylesheet,
etc). In other words, we need to first resolve these questions in HTML5
specs, before we worry about the transport.. otherwise cart before the
horse...

And, all of that aside, we do have a solution: serve the appropriate HTML
to different clients. (just add a Vary: User-Agent.. oh wait - *ducks* :-))

ig

---

From: Roberto Peon <[email-masked]>
Date: Mon, 21 Jan 2013 20:22:41 -0800

Many mobile sites do content inlining because it REALLY makes a difference
in latency/responsiveness. The problem of when to do this is the same
problem. Those who do not do it have a clientele which suffers
significantly higher latency.
The mechanism to decide whether to do this or not can be based upon
user-agent, dst IP, src IP, URL, or configuration of the
server/proxy/accelerator, and is mostly orthogonal to the features of the
protocol-- it is ultimately up to whomever is using the server, configuring
the router/DNS, creating the content to decide how best to serve their
content to the various devices. It is (I think) our problem to ensure that
they have mechanisms available that allow them to do this in efficient ways
when they so choose.

-=R

On Mon, Jan 21, 2013 at 8:06 PM, Mark Nottingham <[email-masked]> wrote:

> > The same way one would in a non-push world-- determine if it is mobile
> and serve the most appropriate content... :)
>
> Yes and no. Today, you have the option of doing it server-side *or*
> client-side. When the server is pushing, all the decisions are made
> server-side. That means, for example, that it'll be potentially more
> difficult to server a responsive site that's completely static.
>
>
> --

---

From: Frédéric Kayser <[email-masked]>
Date: Tue, 22 Jan 2013 09:19:39 +0100

Ok,
I'm familiar with the data URI scheme used by front-end developers. Since "push" is way closer to the server it will probably require the creation of "pushing rules" (if this HTML page is requested push this CSS file and these background images along) or is it envisioned that the server could parse HTML/CSS files to automatically pick up other resources to push, or even train some kind of IA to learn which file request is usually followed by other requests and anticipate such patterns?

Frédéric

---

From: Roberto Peon <[email-masked]>
Date: Tue, 22 Jan 2013 02:01:13 -0800

The idea that is in my mind is that people would innovate and the best
ideas would win out. :)

Personally, I suspect there are a few winning approaches, the first being
page static analysis and rewrite (which you mention) which is in use for
HTML for HTTP today, the second being the server learning based on what the
clients ask for (either by examination of the request stream, examination
of referrers, or reaping of timing stats about page loads), and the third
being the content developer specifies.

The latter two approaches are in use today, with mod_spdy pushing what the
content-owners tells it to (by including a 'x-associated-resource' from
cgi, "Headers" directive, or similar), and with Jetty doing some learning.
I don't know of anyone doing the first yet, but, I'd guess it was only a
matter of time and would likely be a selling feature in/for the various
acceleration services.

-=R

On Tue, Jan 22, 2013 at 12:19 AM, Frédéric Kayser <[email-masked]> wrote:

> Ok,
> I'm familiar with the data URI scheme used by front-end developers. Since
> "push" is way closer to the server it will probably require the creation of
> "pushing rules" (if this HTML page is requested push this CSS file and
> these background images along) or is it envisioned that the server could
> parse HTML/CSS files to automatically pick up other resources to push, or
> even train some kind of IA to learn which file request is usually followed
> by other requests and anticipate such patterns?
>
> Frédéric
>

---

From: Patrick McManus <[email-masked]>
Date: Tue, 22 Jan 2013 09:53:57 -0500

honestly I do think push can, and should, be refined a bit for reasons of
bandwidth (and cost) conservation in some envs. Even the notiion of
Have-Subresources:: etag set (or hash of set, or whatever) probly gets a
long way.

---

From: Roberto Peon <[email-masked]>
Date: Tue, 22 Jan 2013 07:17:13 -0800

I don't disagree-- that would be nice. :)

I just want to be sure that we're not tying server push to a requirement
that we generate a usable refinement (e.g. cache hinting)-- If we do that,
we again force people to inline, which wouldn't be anywhere as easy to
refine in the future.
-=R

---

From: Karl Dubost <[email-masked]>
Date: Tue, 29 Jan 2013 13:11:17 -0500

> Also, it'd be REALLY nice to think about about what this means for responsive design; e.g., if I'm a mobile, I don't need the desktop stylesheet, and maybe not some of those images too. So, how doe…

Related on CSS mailing-list
Media Queries and optimizing what data gets transferred
http://lists.w3.org/Archives/Public/www-style/2013Jan/0434.html

> What inspires me to write this e-mail to www-style today is a proposal
> from Google that seeks to work around this problem on the HTTP level.
> I think working around the design of Media Queries on the HTTP level
> is the wrong solution. I think it would be much better to adjust the
> way Media Queries work so that they don't need to be worked around.
> 
> The proposal comes in the form of a slide deck
> 
> https://docs.google.com/presentation/d/1y_A6VOZy9bD2i0VLHv9ZWr0W3hZJvlTNCDA0itjI0yM/edit
> 
> and an RFC-style draft
> 
> https://github.com/igrigorik/http-client-hints/blob/master/draft-grigorik-http-client-hints-00.txt

The entire thread
http://lists.w3.org/Archives/Public/www-style/2013Jan/thread.html#msg434

-- 
Karl Dubost, a Web opener to hire
http://www.la-grange.net/karl/