Re: SRI for preemptive cache validation

On Tue, May 26, 2015 at 6:51 AM, Ilya Grigorik <igrigorik@gmail.com> wrote:

> On Thu, May 21, 2015 at 11:29 AM, Brian Smith <brian@briansmith.org>
> wrote:
>
>>
>> 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.
>

I think there's *lots* of cases where it is the best thing to do. Browsers
already use very simple machine learning systems to predict these things.
I'd be surprised if nobody starts doing prefetching like this based on
their predictive logic. At least, I think there should be a way for a page
to opt into such 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.
>

When you say "provides," do you mean that it already works, or did you mean
"should provide, when it is implemented in browsers"? It seems quite a few
people have tried to go the "push 304" route getting it to work, so if it's
already working in some browsers it would be good to have an example to
show people.

Anyway, as far as this thread is concerned, I think we mostly agree that
this can/should be solved using HTTP/2 performance optimizations, instead
of SRI. It's worth having a discussion of the pros/cons of the "push 304"
mechanism and alternatives, but probably not here on webappsec. (But where?)

Cheers,
Brian

Received on Tuesday, 26 May 2015 18:44:02 UTC