Re: SRI for preemptive cache validation

On Thu, May 21, 2015 at 1:00 AM, Jeff Kaufman <jefftk@google.com> wrote:

> On Thu, May 21, 2015 at 12:32 AM, Brian Smith <brian@briansmith.org>
> wrote:
> > 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.
> >
>
> Could you explain more what you mean here?  All the interpretations I
> have give me something that's higher latency than pushing 304s.
>


The browser has the HTML for https://example.org/ in its cache. That cached
HTML contains references to https://example.org/background.jpg,
https://example.org/iframe.html, etc. When the browser sends the
(conditional) request for https://example.org/ to the server, at the same
time it also sends conditional requests for
https://example.org/background.jpg and https://example.org/iframe.html if
they are not fresh.

Pushing prementive 304 would require synthesizing "push promise" requests
for https://example.org/background.jpg and https://example.org/iframe.html.
But, the browser has already sent those requests, so the server wouldn't
need to synthesize a push promise for them. And, if either or both of those
resources are fresh in the browser's cache, then the requests and responses
for either or both of them can be completely avoided, freeing up resources
for other things.

Cheers,
Brian