23878 2013-11-20 22:03:31 +0000 Define a fetch registry 2016-08-24 13:32:53 +0000 1 1 1 Unclassified WHATWG Fetch unspecified Other All RESOLVED MOVED P2 normal Unsorted 1 hsteen annevk annevk bkelly bzbarsky ian igrigorik jungkees mike mkwst public-webapps tyoshino zcorpan sideshowbarker+fetchspec oldest_to_newest 96603 0 hsteen 2013-11-20 22:03:31 +0000 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. 96628 1 annevk 2013-11-21 11:38:33 +0000 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. 106572 2 annevk 2014-05-21 14:30:00 +0000 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. 112421 3 ian 2014-09-29 21:19:51 +0000 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"? 112422 4 ian 2014-09-29 21:20:19 +0000 (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) 113173 5 annevk 2014-10-15 08:11:24 +0000 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. 113237 6 ian 2014-10-15 19:04:55 +0000 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? 113278 7 annevk 2014-10-16 07:55:45 +0000 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. 113328 8 ian 2014-10-16 16:30:13 +0000 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. 113333 9 annevk 2014-10-16 16:39:51 +0000 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. 113406 10 ian 2014-10-17 23:48:41 +0000 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. 113412 11 annevk 2014-10-18 09:20:30 +0000 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. 113499 12 ian 2014-10-20 21:44:55 +0000 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. 113523 13 annevk 2014-10-21 07:37:01 +0000 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? 113547 14 ian 2014-10-21 22:50:47 +0000 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...". 114230 15 annevk 2014-10-30 11:29:37 +0000 I'm not a big fan of taking all that on in Fetch, but since nobody else is volunteering, will investigate. 118010 16 annevk 2015-02-18 14:08:41 +0000 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"). 118094 17 annevk 2015-02-23 17:14:41 +0000 https://gist.github.com/annevk/5496188 120896 18 igrigorik 2015-06-10 23:44:30 +0000 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 120898 19 annevk 2015-06-11 05:09:51 +0000 We cannot expose redirects: https://fetch.spec.whatwg.org/#atomic-http-redirect-handling 120907 20 annevk 2015-06-11 14:47:14 +0000 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. 121207 21 jungkees 2015-06-18 06:09:11 +0000 > 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. 127223 22 annevk 2016-08-24 13:32:53 +0000 https://github.com/whatwg/fetch/issues/81 is the successor to this issue.