Re: SRI for preemptive cache validation

On Tue, May 19, 2015 at 9:57 AM, Jeff Kaufman <jefftk@google.com> wrote:

> On Tue, May 19, 2015 at 9:28 AM, Jeff Kaufman <jefftk@google.com> wrote:
> > Yes, for the same origin HTTP/2 case I think pushing 304s could do
> > what we need here. Just to confirm, if a server pushes:
> >
> >     resource: /example.js
> >     status: 304 Not Modified
> >     etag: foo
> >
> > and the browser has /example.js in cache with ETag 'foo', then if the
> > browser would otherwise have made an "if not modified" request with
> > ETag "foo" it instead treats it as already validated?
> >
>
> Update: I just tested this with SPDY/3.1 in Chrome and Firefox and
> pushing 304s doesn't work this way.  Details in
> http://www.jefftk.com/p/preemptive-cache-validation-pushing-304s
>

My understanding is that eventually it is supposed to work, though it might
not work now. You will probably get better help with that on the IETF's
ietf-http-wg mailing list and/or Chrome's net-dev mailing list and/or
Mozilla's dev-tech-network mailing list. It wouldn't be surprising to find
that browsers haven't implemented all of the cache-related push
functionality yet, because it requires an additional communication path
between the browser's HTTP cache and its transaction scheduler that wasn't
previously needed. See [1].

Note also that the browser can (should) pre-emptively conditionally request
the subresources so that the server doesn't have to pre-emptively send 304
responses for them. If/when browsers do that, that should work out better
than the server guessing what the client will ask for.

Cheers,
Brian

[1] https://code.google.com/p/chromium/issues/detail?id=328167