4.6 Integrate the processing model with Fetch

[yoavweiss]

• [x] The algorithm should be called (probably from Fetch) with clear inputs.
• [x] Step 1 - need to replace "fetched by a cross-origin stylesheet fetch with no-cors policy" with defined concepts related to the Request object.
• [x] Step 2 - replace "triggered by..." with well-defined concepts related to the Request object
• [x] Step 4 - startTime needs to be recorded as part of Fetch and communicated to the processing mode
• [x] Step 5 - The processing model of initiatorType needs to be defined in terms of Fetch. See https://github.com/w3c/resource-timing/issues/246
• [x] Step 6 - define in terms of Fetch. See https://github.com/w3c/resource-timing/issues/244
• [x] Step 7 - fetchStart needs to be recorded as part of Fetch and communicated to the processing mode
• [x] Step 8 - Seems spurious if a fetch is not initiated or terminated. Needs to fall out from the integration between Fetch and this processing model. May require definition of the Memory/Preload Cache. See https://github.com/whatwg/fetch/issues/590
• [x] Step 9 - workerStart definition should be set by Fetch/ServiceWorkers and communicated to this processing model
• [x] Step 12 - replace "resource is fetched from" with well-defined concepts
• [x] Steps 13-15 - domain lookup and connection times are not currently defined in Fetch. Need to investigate to see if/how they can be better defined.
• [x] Step 16 - "secure transport is used" needs to be replaced with Fetch concepts. Better definition of the connection times needs to be investigated.
• [x] Step 17-19 - Set requestStart, responseStart and responseEnd of part of Fetch processing.
• [x] Step 19.2 - define transferSize, encodedBodySize and decodedBodySize in terms of Fetch. Note that on transferSize, we may want to omit the header size: https://github.com/w3c/resource-timing/issues/238
• [x] Step 21 - Define redirect processing as part of the Fetch processing model
• [x] Define if entry is queued before or after the load event https://github.com/w3c/resource-timing/issues/82

[noamr]

I'm seeing to ways to possible ways to go about this:

1. keep the data as a struct inside fetch, and call resource timing only at the end of the response with all the info. This would basically mean keeping a lot of timing information inside the fetch spec.
2. Call resource timing from multiple locations with different parameters.

I'm currently leaning towards (2), but would love to run it by you first, @annevk and @yoavweiss. Note that the implementations look more like (1), where the network stack saves all the info internally in its own data structure until it's time to "mark".

[annevk]

What do you mean with "at the end of the response"? When it's returned to the caller or when it reaches end-of-body? If the data structures are actually tightly coupled with a response I think it would be better to specify it that way. That also enables new types of APIs and seems like a more solid foundation than calling out to something. (It's also not immediately clear to me how that calling out would work across conceptual threads and such.)

[noamr]

What do you mean with "at the end of the response"? When it's returned to the caller or when it reaches end-of-body? If the data structures are actually tightly coupled with a response I think it would be better to specify it that way. That also enables new types of APIs and seems like a more solid foundation than calling out to something. (It's also not immediately clear to me how that calling out would work across conceptual threads and such.)

Yes, they're pretty tightly coupled. It's maybe better to save everything as a structure in fetch and pass it as a parameter to resource-timing when it's time to mark (as the implementations do anyway).

[annevk]

Yeah, we have structs to be clear, see https://fetch.spec.whatwg.org/#fetch-params for an example. (Although I suspect here we'd store it on the response.)

[noamr]

What do you mean with "at the end of the response"? When it's returned to the caller or when it reaches end-of-body? If the data structures are actually tightly coupled with a response I think it would be better to specify it that way. That also enables new types of APIs and seems like a more solid foundation than calling out to something. (It's also not immediately clear to me how that calling out would work across conceptual threads and such.)

Looking closer, data structures are more tightly coupled with the request than with the response. For example, some metrics such as workerStart and fetchStart need to be measured in some cases before the response object is constructed. We can either create one struct and associate it with the request, or create separate request and response timing structs, which seems perhaps unnecessary.

[annevk]

That makes sense and some of that duplication exists today as well. I don't have a good handle on when these things are exposed, but if they are not exposed before a response is exposed, I think we should end up exposing them on the response and use "fetch params" or maybe "request" as a place to do bookkeeping until there is a response. If they are exposed at some other point fetching might need new callbacks, but I hope that's not needed.

[noamr]

OK, I'll put it as a field of fetch params and later expose it in the response.

[noamr]

• The algorithm should be called (probably from Fetch) with clear inputs.

Will be closed by https://github.com/w3c/resource-timing/pull/261

• [x] Step 1 - need to replace "fetched by a cross-origin stylesheet fetch with no-cors policy" with defined concepts related to the Request object.

Closed by https://github.com/whatwg/fetch/pull/1185

• [ ] Step 2 - replace "triggered by..." with well-defined concepts related to the Request object

Closed by https://github.com/whatwg/fetch/pull/1185

• [ ] Step 4 - startTime needs to be recorded as part of Fetch and communicated to the processing mode

Closed by https://github.com/whatwg/fetch/pull/1185

• [ ] Step 5 - The processing model of initiatorType needs to be defined in terms of Fetch. See #246

Will be closed by https://github.com/w3c/resource-timing/pull/261

• [ ] Step 6 - define in terms of Fetch. See #244

Closed by https://github.com/whatwg/fetch/pull/1185

• [ ] Step 7 - fetchStart needs to be recorded as part of Fetch and communicated to the processing mode

Closed by https://github.com/whatwg/fetch/pull/1185

• [ ] Step 9 - workerStart definition should be set by Fetch/ServiceWorkers and communicated to this processing model

Closed by Closed by https://github.com/whatwg/fetch/pull/1185 Note that for navigation timing workerStart means something different, see https://github.com/w3c/ServiceWorker/pull/1575

• [ ] Step 12 - replace "resource is fetched from" with well-defined concepts

Closed by https://github.com/whatwg/fetch/pull/1185

• [ ] Steps 13-15 - domain lookup and connection times are not currently defined in Fetch. Need to investigate to see if/how they can be better defined.

Closed by https://github.com/whatwg/fetch/pull/1185

• [ ] Step 16 - "secure transport is used" needs to be replaced with Fetch concepts. Better definition of the connection times needs to be investigated.

Closed by https://github.com/whatwg/fetch/pull/1185

• [ ] Step 17-19 - Set requestStart, responseStart and responseEnd of part of Fetch processing.

Closed by https://github.com/whatwg/fetch/pull/1185

• [ ] Step 19.2 - define transferSize, encodedBodySize and decodedBodySize in terms of Fetch. Note that on transferSize, we may want to omit the header size: #238

238 still holds. The rest are closed by https://github.com/whatwg/fetch/pull/1185

• [ ] Step 21 - Define redirect processing as part of the Fetch processing model

Closed by https://github.com/whatwg/fetch/pull/1185

[noamr]

I believe this can be closed, and we can continue tracking https://github.com/whatwg/html/issues/6542. WDYT @yoavweiss ?

[yoavweiss]

LGTM