Please consider "HTML fetch" obsolete when you do this. Please first review and request appropriate hooks. The current setup is very barebones and requires setting up requests to pass to fetch and handling responses that are returned. I'm fine with adding sugar, but I have not yet figured out exactly what that should be myself.

So in bug 24137 comment 19 you say we need to pick the right event loop. This would be a "networking task source" associated with a set of browsing contexts or a worker. So should you pass in either a Document or a WorkerGlobalScope as a handle for Fetch to find the relevant things?

Ideally I'd pass in an event loop, no? I'm not really sure.

How confident are you in the current fetch spec text?

What exactly is it I should be merging in? In bug 24613 you said something about one of the algorithms being something you want back into HTML?

The problem I have is that everyone uses Fetch, but nobody really cares about the details and overall platform coherence. So it's really hard to figure out what parameters Fetch needs and what the easiest setup could be given the various requirements we have.

E.g. for service workers we need a global. We can use that global for CSP too. Can we use it for Referer determination (also partially a CSP matter these days)? We always need an origin, does that need to be passed in explicitly, or can we get that from a global too?

Most of the structure is sound I think, but the details are not cemented.

Once HTML uses this, it should use the http://fetch.spec.whatwg.org/#concept-fetch algorithm almost directly, perhaps with shorthands defined for more complicated fetching scenarios, such as "image fetch".

(Currently discussing Fetch's use of 'client' in webappsec.)

Why do you need a global for service workers?

Currently we check if the client (environment / global object) is from a service worker to go directly to the network. (We also use that client for referrer, origin, etc.)

Maybe we should extend the script settings object to just me an "environment settings object", and shunt that around. That would let us maintain specific referrers, origins, event loops, etc, things that aren't always set with a global or Realm. There's a global hung off the side of the settings object already.

An environment settings object would work for me. That would indeed help with queuing tasks on the right event loop as well.

https://github.com/whatwg/html/issues/95