Re: [fetch] Initializing context/content specific fetch defaults (#43)

@annevk I'll defer to you on `createResponseURL` vs. `srcObject`, you have much better context there.

@yoavweiss I agree with @annevk I think changing priorities is an orthogonal discussion. "as" is used to initialize request defaults, other options provided by the developer would override them. For example...

```
fetch(url, {as:"image", headers: {"Accept": "custom/format, image/jpeg"}})
```

* `as` would set the default image Accept header
* User provided headers would override the defaults

Changing prioritization would work the same way, we "just" need to define syntax to control transport priorities and dependencies... [previous discussion on whatwg](https://docs.google.com/document/d/1jSpWc6jkrUoYtGWcxev9Blkkv9RhoO1XtqinBvXqhgY/edit). Assuming we arrive at some such thing, it could potentially look as... _*commence handwaving...*_

```<link rel=preload href=photo.jpg as=image fetch-settings="{headers: {..}, priority: {..}}">```

Or some such.

---

On a more tactical level, I'm wondering if we can unblock Resource Hints / Preload and continue iterating on other details in parallel... Concretely:

* Add some language to Fetch to recognize `as` fetch option, with some starter language to indicate that it should be used to enforce security policies and initialize request defaults.
* In RH/Preload I can link "as" attribute value to this Fetch option. 

The response blob vs. URL does not block either RH or Preload because both are used to populate the cache, and are then consumed by another element/object that would enforce its CSP policy.

@annevk wdyt, does that sound reasonable? I'd love to land the RH and Preload refactors, as they're blocking implementation in Blink.

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