Observer API for fetch groups

[igrigorik]

Continuation of https://www.w3.org/Bugs/Public/show_bug.cgi?id=23878#c20.

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.

[1] w3c/performance-timeline#13 (comment)

[martinthomson]

I think that it would be best if the request triggered the observer. I'm sure that there are other reasons, but off-the-cuff it would a) fit best with server push support, b) allow for observation of the entire exchange, and c) allow applications to implement logic that avoids redundant requests.

Would a more concrete proposal help here?

[annevk]

If this is something you'd like to implement soonish that would definitely help. I'm mostly focused on Fetch integration with Service Workers, Streams, and most things WebAppSec.

[rektide]

I have an example of this usage pattern (a (node) client observing push_promises) in a server-to-server case- I stream IRC messages from one microservice to another.
https://github.com/rektide/tele-pump/blob/master/tele-muc-pump.js#L17

I also have tooling to notify the client of push_promises: I record all push_promises i send, then attach a X-Associated-Content header listing these pushed resources to responses to real requests. The client has to run a monkeypatched XHR, which is responsible for stripping out this header and postMessaging to the window a notice of this new content.
https://github.com/rektide/pushchannel

Would love a legit observer api, such that the first project could work without this out-of-band signaling invented in the second project.

[CTJyeh]

I am interested in observing all resource requests that have been initiated, but has not been completed (and their respective timing information). This is mostly to track which resources have not complete in x number of seconds as seen by the client.

[nicjansma]

Besides some of the use cases described in w3c/performance-timeline#13 (comment), we're also having a need for a Fetch Observer when trying to develop a Time-To-Interactive metric that's based on signals like LongTasks, FPS, and networking activity.

We'd like to know when networking activity is below some level (i.e. n resources outstanding), and there's no way to do this today in a complete and performant way.