This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 23878 - Define a fetch registry
Summary: Define a fetch registry
Status: RESOLVED MOVED
Alias: None
Product: WHATWG
Classification: Unclassified
Component: Fetch (show other bugs)
Version: unspecified
Hardware: Other All
: P2 normal
Target Milestone: Unsorted
Assignee: Anne
QA Contact: sideshowbarker+fetchspec
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-11-20 22:03 UTC by Hallvord R. M. Steen
Modified: 2016-08-24 13:32 UTC (History)
11 users (show)

See Also:


Attachments

Description Hallvord R. M. Steen 2013-11-20 22:03:31 UTC
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.
Comment 1 Anne 2013-11-21 11:38:33 UTC
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.
Comment 2 Anne 2014-05-21 14:30:00 UTC
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.
Comment 3 Ian 'Hixie' Hickson 2014-09-29 21:19:51 UTC
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"?
Comment 4 Ian 'Hixie' Hickson 2014-09-29 21:20:19 UTC
(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)
Comment 5 Anne 2014-10-15 08:11:24 UTC
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.
Comment 6 Ian 'Hixie' Hickson 2014-10-15 19:04:55 UTC
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?
Comment 7 Anne 2014-10-16 07:55:45 UTC
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.
Comment 8 Ian 'Hixie' Hickson 2014-10-16 16:30:13 UTC
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.
Comment 9 Anne 2014-10-16 16:39:51 UTC
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.
Comment 10 Ian 'Hixie' Hickson 2014-10-17 23:48:41 UTC
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.
Comment 11 Anne 2014-10-18 09:20:30 UTC
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.
Comment 12 Ian 'Hixie' Hickson 2014-10-20 21:44:55 UTC
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.
Comment 13 Anne 2014-10-21 07:37:01 UTC
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?
Comment 14 Ian 'Hixie' Hickson 2014-10-21 22:50:47 UTC
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...".
Comment 15 Anne 2014-10-30 11:29:37 UTC
I'm not a big fan of taking all that on in Fetch, but since nobody else is volunteering, will investigate.
Comment 16 Anne 2015-02-18 14:08:41 UTC
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").
Comment 17 Anne 2015-02-23 17:14:41 UTC
https://gist.github.com/annevk/5496188
Comment 18 Ilya Grigorik 2015-06-10 23:44:30 UTC
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
Comment 19 Anne 2015-06-11 05:09:51 UTC
We cannot expose redirects: https://fetch.spec.whatwg.org/#atomic-http-redirect-handling
Comment 20 Anne 2015-06-11 14:47:14 UTC
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.
Comment 21 Jungkee Song 2015-06-18 06:09:11 UTC
> 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.
Comment 22 Anne 2016-08-24 13:32:53 UTC
https://github.com/whatwg/fetch/issues/81 is the successor to this issue.