Re: [fetch] Introduce convenience property for request's context (#93)

I'm going round and round in circles on this. Here are some thoughts at least:

In order to correctly serve a fallback, we're looking for a hint as to how the response will be processed. A page navigation is "any" in this case. This is distinct from content-types as an `<img>` will accept a resource of `text/html` but process as an image. For this particular use-case, `isNavigation` gets us most of the way there.

Preload wants a hint for the request type, so it can set correct headers and match the request up later.

CSP wants a hint as to how the response will be processed, but also wants the initiator in the case of forms.

Based on CSP, here are a set of processors:

* connect
* font
* img
* media
* object
* script
* style
* other

Specs using fetch should use "other" if a new type isn't necessary for CSP (eg, "manifest").

Additionally, we need to know the type of client this response creates:

* document
* child-document
* worker
* sharedworker
* serviceworker
* subresource (does not create a client)
* unknown (for objects without `typemustmatch`)

…or no value, for a non-client request.

To cover the edge cases, CSP gets a bit to indicate a form submission, although it'd be great if it were redefined in terms of post/get requests the page could make. `child-src` can be determined through the client-creation type, `script-src` can be determined by "script" that doesn't create a client. 

Preload `as` would take the processing types and map them to request types in terms of `as`.

ServiceWorker can determine navigation and framing through "document" and "child-document", and can serve a fallback image for "img". Not sure context-frame is needed.

---
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/93#issuecomment-126686379