Bug 172646 – Abort HTTP/2 push streams if the item is already in the HTTP cache

• Status: NEW
• Component: Page Loading

[Jake Archibald]

Chrome is getting ready to ship this https://bugs.chromium.org/p/chromium/issues/detail?id=232040, and as far as I can tell, Edge already shipped it.

Currently Safari *sometimes* rejects push streams if the item is in the HTTP/2 push cache. As far as I can tell, it'll abort the stream if all of the following is true:

* The item in the push cache is 'fresh' according to cache headers
* The user did not hit 'refresh'

[Radar WebKit Bug Importer]

<rdar://problem/32437593>

[youenn fablet]

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.

[Jake Archibald]

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.

[Jake Archibald]

I threw together a little test server at https://github.com/jakearchibald/http2-push-test - this may help.