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

@sleevi - I wasn't talking about coalesced origins; for the moment, let's figure this out for same-origin (while still acknowledging that coalescing will raise its head at some point).

Thanks for giving concrete examples.

WRT `should request be blocked due to nosniff`, that step is run after `http network or cache fetch`, so it will still apply to requests if you model server push as being placed into the HTTP cache. The request type is available at request time, and will be appropriately applied to the decision. How the response actually got stored in the cache isn't really an issue AFAICT.

WRT `request destination`, I'm afraid it's not clear to me. HTTP caches can be and are deployed at many places in the path between the browser and the origin server, including on the same box as the browser. Server push will get into those caches (as well as other responses from a variety of request contexts), the browser will get responses from them without any notion of the internals of Fetch. How is the HTTP cache special?

I went through the rest of the Fetch spec as you asked, and didn't see any immediate problems. Can you point out any more? Happy to admit I'm missing something here, because I know you have a deeper understanding of the internals here.

I totally get that browsers may have made some optimisations in their implementations by assuming that things that successfully get into the HTTP cache have specific attributes. I can even see that from an implementation perspective, it makes sense to create a separate cache for pushes or to taint them because of historical implementation decisions. I'm just not yet seeing a reason to call it a different kind of cache in the specs yet, when the specs appear to already be written in a manner where It Just Works, more or less. 


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

Received on Monday, 27 February 2017 04:59:31 UTC