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

> If this is what you refer to when you talk about "an initiation of fetch has a context (in the page and origin) that exceeds the available information in a PUSH PROMISE", then we're probably just in agreement on the need to walk through the wrinkles.

It's not what I meant, so at least now we've found the source of confusion.

Start with the algorithm described in https://fetch.spec.whatwg.org/#http-fetch , and work through every place where "return a NetworkError" is specified. Then look at what conditions cause that. You will see there is more context than 'just' the URL.

For example, the algorithm in https://fetch.spec.whatwg.org/#should-response-to-request-be-blocked-due-to-nosniff? is dependent on https://fetch.spec.whatwg.org/#concept-request-type which is dependent on the element or context in the page that caused the fetch.

https://fetch.spec.whatwg.org/#concept-request-destination is perhaps an even clearer highlighting of the variations in the processing model that affect things during Fetch.

As it stands in the world today, where user agents do not allow direct pushes into the HTTP cache, there are a number of ways in which a request from `example.com` to `example.net` can be stopped or blocked before any information is sent or stored. A PUSH PROMISE that is allowed to enter the HTTP cache fundamentally changes that.

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