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. ig
Received on Tuesday, 26 May 2015 16:52:17 UTC