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

@mnot I totally appreciate your perspective coming at it from the view of a server operator, because I think it's important to distinguish between what's observable to the client, what's observable to the server, what's observable to intermediates, and what's observable to the user. My premise is that any observable differences should be spec'd - whether that appears in HTTP (and related) in the side of IETF, or in Fetch (and related) from the perspective of the client here - and my focus has been on observable behaviours emitted from the client or affecting the user. This is mostly out of selfish interest - I can influence client behaviour, but I can't help server behaviours and how they cache or if they cache appropriately.

For same-origin fetches, I agree with you that it's unlikely to be problematic from either a security perspective or a network-observable perspective. This is why Chrome is [exploring implementation options](https://groups.google.com/a/chromium.org/d/msg/net-dev/mWeuVhhpGhc/ejrFBn45AQAJ) to better optimize the H/2 experience, and why there is still a lot of [discussion around rel=preload](https://groups.google.com/a/chromium.org/d/msg/net-dev/CCNLknIbzYs/yNmiUaHQAQAJ) and the H/2 cache.

In discussing the processing model, the following stand out for same-origin fetches:
* When a Service Worker is present, it's possible that the SW will intercept all requests for `/a.js` and potentially rewrite them, therefore it suggests we shouldn't allow a PUSH PROMISE into the Cache. The counter-argument is that because it's Same-Origin, the SW 'could' be configured to allow or fetch `/a.js`. This creates an asymmetry in capabilities that's uncomfortable, but it does not seem to intrinsically create additional risk, so it's probably OK.
* We can ignore the processing model for redirects, using the same logic as above - yes, it's an asymmetry, but the server 'could' be redirecting to the pushed resource as the final URL.
* The cache mode follows the `Request`, so directly inserting a PUSH PROMISE into the cache meaningfully changes that process model. In this case, Step 20 of [HTTP-network-or-cache-fetch](https://fetch.spec.whatwg.org/#http-network-or-cache-fetch). This is why we're exploring making PUSH PROMISE handling cache aware, to reduce the overhead involved in PUSH promises.

This is why I think that, generally speaking, we (Chrome folks) have mostly convinced ourselves that same-origin pushes to the cache are _probably_ OK. However, there's a big looming question mark on whether it's the right thing for the user - when it's done right, it can reduce latency, but when it's done wrong, it can waste users' bandwidth and disk space. Further, as you've alluded to, from an implementation perspective, there's a lot of complexity - perhaps intractably so, given the API surface exposed - that doesn't have a lot of people jumping for joy at supporting either same-origin or cross-origin. An example of this is the intersection with the [webRequest](https://developer.chrome.com/extensions/webRequest) API and how that affects resource consumption - e.g. imagine an advertiser pushing assets to the client when they're running an ad-blocker.

The fact is, as far as implementations go, it *is* a different cache, and that's unlikely to change in the near future precisely because of the various complexities. So to the extent @annevk likes specs to reflect the real world, I'm wholly supportive of it. However, if other implementations are doing things differently, then it's something to explore and evaluate, but better to have the spec reflect truth.

-- 
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-282631493