- From: Brian Smith <brian@briansmith.org>
- Date: Tue, 26 May 2015 08:43:35 -1000
- To: Ilya Grigorik <igrigorik@gmail.com>
- Cc: Jeff Kaufman <jefftk@google.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Joel Weinberger <jww@google.com>
- Message-ID: <CAFewVt6htjVRSgQS3Ou+79SuNv3sxnBrDUnPXzp=ycS2j3vLgQ@mail.gmail.com>
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