Summary: | Abort HTTP/2 push streams if the item is already in the HTTP cache | ||
---|---|---|---|
Product: | WebKit | Reporter: | Jake Archibald <jaffathecake> |
Component: | Page Loading | Assignee: | Nobody <webkit-unassigned> |
Status: | NEW --- | ||
Severity: | Normal | CC: | achristensen, beidson, webkit-bug-importer, youennf |
Priority: | P2 | Keywords: | InRadar |
Version: | Safari Technology Preview | ||
Hardware: | Unspecified | ||
OS: | Unspecified |
Description
Jake Archibald
2017-05-26 08:01:35 PDT
There might be cases where it makes sense to process the pushed content, for instance if the push purpose is to refresh or invalidate the cache. There might be other edge cases as the push cache may be different from the http cache. For instance, a request bypassing the HTTP cache might not bypass the push cache. I agree the spec isn't clear when the push should be cancelled. There's some discussion of this in the Chrome issue, eg https://bugs.chromium.org/p/chromium/issues/detail?id=232040#c62 Personally, it enters a grey area when the pushed resource is clearly fresher than the item in the HTTP cache (from last-modified or etag headers). However, it seems pretty clear-cut if the pushed item has the same last-modified/etag header as the item in the HTTP cache - continuing to receive this is a waste of bandwidth. If the item in the cache is fresh, and it isn't clear if the pushed item is fresher, rejecting the stream still feels like the right thing to do, as HTTP/1 users would use the cached item. I threw together a little test server at https://github.com/jakearchibald/http2-push-test - this may help. |