Re: [whatwg/fetch] Define a cache for H2 server push & friends (#354)

@mnot I wouldn't say that they're equivalent.

The loading of a resource (that is, the attacking page is not same-origin
as the receiving page) results in a different request flow than a push
(even a push associated with a specific stream serving the attacking page's
content). This is because any step that could block a network load as part
of processing https://fetch.spec.whatwg.org/#http-fetch becomes an
observable difference for non-same origin pushes. Since CORS is the most
likely thing to cause a network error event, this makes 3P pushes almost
certainly SOP violations.

Even if it was limited to same-origin pushes, there's the question of
whatever a specific implementation does as part of general processing (e.g.
safe browsing checks, image blocking checks, etc). Whenever something is in
the cache, it will have gone through all of those checks today. If any of
those checks rely on the context of understanding what page content
'initiated' the request - whether they be UA specific or even the common
checks in fetch that rely on the 'type' of the fetch - then these end up
with observable differences, both to the page and to the user (who may not
want such requests stored to disk).

I'm not sure if you were trying to suggest that was an "overabundance of
caution", but I think that's the set of concerns of why I think going in
any direction to allow H2 PUSH to push to the HTTP Cache will involve some
degree of discussion around the Fetch spec and tests.


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/354#issuecomment-282232803