W3C home > Mailing lists > Public > public-webappsec@w3.org > May 2015

Re: SRI for preemptive cache validation

From: Ilya Grigorik <igrigorik@gmail.com>
Date: Tue, 26 May 2015 09:51:07 -0700
Message-ID: <CAKRe7JFMouOkjFR+rUVf=BVvKZ9WYdBwoQ7aYcFF9p9SMbBFbw@mail.gmail.com>
To: Brian Smith <brian@briansmith.org>
Cc: Jeff Kaufman <jefftk@google.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Joel Weinberger <jww@google.com>
On Thu, May 21, 2015 at 11:29 AM, Brian Smith <brian@briansmith.org> wrote:

> 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.

This means that the browser is speculatively requesting resources based on
a stale (and potentially invalid) response.. afaik, no browser does this
today. That is, we wait to validate the response before we parse it..
which, I think, is the right behavior.

Pushing resource 304's alongside the HTML 304 allows the server to
revalidate all the resources within one RTT -- this preserves correctness
and provides a nice performance win.

Received on Tuesday, 26 May 2015 16:52:17 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:49 UTC