On 19 August 2014 01:02, Edward Burns <edward.burns_at_oracle.com> wrote:
> Greg, is this the rationalization used by the httpbis wg to justify not
> handling the problem more explicitly?
>
I can't speak for the WG, but I posted them a link to this thread and ask
for confirmation of my characterisation of the mechanism as follows:
- Push is a server-side coordinated mechanism in as much as the server
must decide to push a resourced based only on information that it already
has. Specifically h2 provides no information on the contents or status of
downstream caches.
- Servers are free to innovate push strategies, with some of the
following having been suggested:
- Use knowledge from the web application/framework to determine what
are associated resources.
- Use heuristics derived from referrer headers and timing to infer
what are associated resources
- Use sessions to track what resources a client has
requested/received to avoid unnecessary pushes
- Use the presence of if-modified headers to infer the status of a
client cache to avoid unnecessary pushes.
- There are no functional problems other than increased latency of
not pushing an associated resource
- There are no functional problems other than wasted bandwidth of
pushing an unnecessary resource:
- Clients can reset a pushed stream if they determine it is
unnecessary. Thus is a server attempts to push a resource that
is already
cached by the client, a RST will prevent wasting too much bandwidth.
This has received an OK from the WG chair and editor.
So to answer your original question, yes it is expected behaviour that
bandwidth can be saved on unnecessary pushes by RST streams.
cheers
--
Greg Wilkins <gregw_at_intalio.com>
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com advice and support for jetty and cometd.