Pushing 304's

I wondering if we may need to change to the semantics of 304 responses a
little  to better support push.


The situation that I'm thinking of is when a browser has a cache full of
associated resources, but that all need to be validated.  Without push,
what we typically see is:

   - request for page.html with I-M-S or I-M header
   - 304 response sent for page.html
   - requests for logo.png, page.css, page.js each with I-M-S or I-M headers
   - 304 responses sent

What we would like to see with push is

   - request for page.html with I-M-S or I-M header
   - 304 response sent
   - 304 responses pushed for logo.png, page.css, page.js

However, the problem is what etag or date should the pushed 304's be
relative to?  Typically the pseudo request used for a push promise will be
based on the original request for page.html, so it will get the same
cookies, user-agent and other headers.   But the etag/date from If-Match or
If-Modified-Since headers for the page.html are not applicable to
associated resources.

So in some cases, the server can look up the associated resources to
determine their last modified time or etag and to put that into the psuedo
request of the push promise.    The client will then have to know that when
it receives a pushed 304 response that it needs to check the etag/date in
the push promise request to see if it matches the version it has in its
cache (and if not re-request).   I think that is something that perhaps we
should call out as a requirement for clients?   Maybe 6.6 could be updated
to have text like:

A receiver MUST check that the headers within a received PUSH_PROMISE match
the headers that would have been sent in a normal request for that
resource. Specifically cookies and conditional headers should to be
verified and the stream rejected if they do not match the receivers
expectations.

I think this is a MUST rather than a SHOULD because I can see situations of
requests coming in for expired sessions.  For example if the page.html
request contains session cookie then pushed resources will be generated
using the same cookie value, possibly before page.html is generated.  If
subsequent processing of page.html invalidates the existing session and
creates a new one with a new cookie value, then the content sent for the
page.html and the associated resources may be for different session!.
Of course servers should probably check the session before doing the push,
but as that can involve the application, that may not always be
possible.    Thus clients MUST check that the pushed resources are indeed
the ones they would have asked for  -including cookies and conditional
headers.


Another issues is that in many cases it is not possible for the server to
actually determine the etag/date to use in a psuedo request.  For example
our server http://webtide.com is running http2 push from it's jetty server,
but the pages themselves are generated from a co-located wordpress instance
(PHP).     When Jetty sends a push promise with a psuedo request, it
simultaneously proxies that same request to the PHP instance to get the
response.   Thus the http2 server cannot easily retrieve the etag or last
modified date.   I think having http2 in a proxy like this will be a
frequent deployment mode.

What I think is required is a semantic that asks for a 304 to be sent that
includes the etag and/or last-modified date.   For example, perhaps we
could define '*' as a value for I-M-S and I-M to mean always send a 304,
but include the reference tag/date.  So in the above case, the psuedo
requests generated for logo.png, page.css, page.js would look like

  :method: GET
  :path: /logo.png
  :authority: host
  if-modified-since: *

and the responses would like:

  :status: 304
  last-modified: Thu, 27 Nov 2014 20:59:51 GMT

If there is concern that a date of * might cause errors on some origin
servers, then perhaps a new header when-modified could be used?

thoughts?




-- 
Greg Wilkins <gregw@intalio.com>  @  Webtide - *an Intalio subsidiary*
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.