This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
In https://github.com/whatwg/xhr/pull/3 annevk says "I guess we'll have to decide what kind of fetch termination happens here though.". This bug is just a reminder to make that decision happen.
So I guess this is about better defining what happens in http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#abort-a-document I guess if that terminates with fatal it's best because that effectively kills XMLHttpRequest the quickest.
Ideally the way this is fixed is that Ian tracks all fetches for a given global/document and just terminates them all. We then just hook into that pool of fetches. Assigning to Ian for consideration.
How can I track what fetches happen for a given document/global/environment settings object? Is that a property of a fetch such that I can just reference "every instance of the fetch algorithm whose foobar is baz"?
(might be best to just use the document unload steps or some such, on the fetch side, though I guess that doesn't help with workers)
No that is not a property of Fetch. And note that we need historical tracking too. E.g. if we ever want to define https://w3c.github.io/web-performance/specs/ResourceTiming/Overview.html properly. Or the idea discussed in https://github.com/w3c/navigation-timing/issues/3 Now we could make Fetch append to some list of the environment settings object to track these things.
I don't understand why this isn't a property of Fetch. Isn't this something that happens regardless of the environment? Say someone invents a new one, like Service Workers or something. Don't we need to also define lifetime rules there?
This is a property likely shared by all environments, yes. You define the environment settings object. It would make some sense to register lifetime things there. Fetch at the moment deals with fetching. It could also extend the environment settings object and start doing logging (effectively), but I'm not convinced that's a good idea.
How is the lifetime of a fetch not part of fetching? I really don't understand what the environment settings object would have here. It's just a struct, it doesn't have behaviour.
Various features require tracking all fetches originating from an environment settings object's global object (or responsible document). So e.g. if I have <!doctype html> <img src=...> <script src=...> this list would contain two resources and perhaps a special entry for the document itself. This list would then be used when the document is closed somehow to terminate ongoing fetches. It would also be used to report timing information (see all the stuff the web performance group introduces without solid normative language around it). This seems out of scope for Fetch, which deals with the life cycle of a single fetch.
The life cycle of a single fetch is exactly what we're talking about here. Fetch should just add each fetch to some per-environment-settings-object list when it starts, and remove each fetch when it ends, and if any are left over when the document goes away it should abort them (except for those it shouldn't abort, like images). If you need hooks for when a settings object is going away, that I can provide, but the lifecycle management seems like something that entirely belongs in Fetch.
If I remove from the list, how would we define e.g. http://www.w3.org/TR/performance-timeline/#dom-performance-getentries properly? I specifically wrote down that this list was used for other things than terminating ongoing activity.
Well you don't have to actually remove it, you could just not do anything with fetches that are already done when you go through the list at shutdown time.
Okay, so the idea is that we add a list to the environment settings object that tracks all Request/Response for that environment settings object. That list can then be used for various performance features. When the environment settings object goes away, HTML pings Fetch and Fetch terminates any ongoing operations within that list, likely triggering some more events inside the environment settings object's global object and then it's done. Sounds about right?
Well I wouldn't trigger any events, and you need to skip terminating those that are magical like <img>, but yeah, basically. You can do the list entirely in Fetch. Just say "Each environment settings object is associated with a list of fetch algorithm instances..." or whatever. Or, have each fetch associated with a settings object, then refer to "all the fetches associated with this settings object...".
I'm not a big fan of taking all that on in Fetch, but since nobody else is volunteering, will investigate.
So here is my tentative plan: * Introduce a "fetch registry". It has a 1:1 relation with environment settings objects. * Introduce "fetch records" that keep track of a fetch. The fetch algorithm creates these and appends them to the registry. They stay there for the lifetime of the environment settings object, so we can explain resource timing and such through it. * Introduce a "keep-alive flag" to explain <img>, ping="", and sendBeacon(). * When an environment settings object goes away (navigation, termination) all fetch records that have an active fetch and no keep-alive flag will have their fetch terminated. Hopefully environment settings objects will get some kind of callback hook for this. Once this is in place we can potentially move some things from request to fetch records (e.g. "redirect count").
https://gist.github.com/annevk/5496188
A couple of requirements/notes that have come up in context of Fetch registry: 1) I'd be nice if there was an ~observer API that allowed an application to be notified when new fetch requests are added to the registry - see discussion in [1]. As a related question: when would fetch objects be made visible, when the request is initiated? If so, then that would be sufficient to solve the use case in [1], and if not then we'd have to investigate alternative routes. 2) For cases where the fetch goes through one or more redirects, it should be possible to see the full route - see [2]. That is, each request in the redirect chain as a separate fetch, plus a way to link them together. [1] https://github.com/w3c/performance-timeline/issues/13#issuecomment-108097288 [2] https://github.com/w3c/preload/issues/14
We cannot expose redirects: https://fetch.spec.whatwg.org/#atomic-http-redirect-handling
https://github.com/whatwg/fetch/commit/744d8b3bbe3b59492cff5f0fdd49b8dd053c4571 addresses this per comment 16. For now I have not moved things from request to fetch records. Fetch records simply hold a pointer to request. We can move things around later if that makes sense for the API. Ian, will you make sure HTML invokes https://fetch.spec.whatwg.org/#concept-fetch-registry-terminate at the right time? Jungkees, service workers also needs to invoke that hook when a service worker dies. Unless you reuse some worker / shared worker infrastructure from HTML for that. Ilya, we should probably discuss the details of the observer API on GitHub. This bug is mostly about setting up the underlying infrastructure.
> Jungkees, service workers also needs to invoke that hook when a service worker dies. Unless you reuse some worker / shared worker infrastructure from HTML for that. Service workers are reusing "terminate a worker" algorithm in HTML.
https://github.com/whatwg/fetch/issues/81 is the successor to this issue.