From a18e4e39001a9c6b165a41fa50162b1b7dfaf6cf Mon Sep 17 00:00:00 2001 From: Noam Rosenthal Date: Fri, 2 Sep 2022 09:14:23 +0300 Subject: [PATCH] Add more timing iformation about (interim) responses See https://github.com/w3c/resource-timing/issues/345 Since early hints have landed, there are additional useful timestamps that are currently not exposed: - First interim response start (e.g. when we received a 103) as a different timestamp from the final response start (e.g. when we received the 200) - Final headers received (when the last header has been received and we're ready for the body) - First bytes of the body received The naming in #345 is not finalized yet, but it's clear that these are the 3 interesting timestamps. This PR exposes those for later use by resource timing. --- fetch.bs | 28 +++++++++++++++++++++++++--- 1 file changed, 25 insertions(+), 3 deletions(-) diff --git a/fetch.bs b/fetch.bs index eca7c7dbb..b85cfa893 100644 --- a/fetch.bs +++ b/fetch.bs @@ -342,7 +342,10 @@ following items: [[RESOURCE-TIMING]] [[NAVIGATION-TIMING]]
post-redirect start time (default 0)
final service worker start time (default 0)
final network-request start time (default 0) +
first interim network-response start time (default 0)
final network-response start time (default 0) +
final network-response headers end time (default 0) +
response body start time (default 0)
end time (default 0)
A {{DOMHighResTimeStamp}}. @@ -5994,9 +5997,8 @@ optional boolean forceNewConnection (default false), run these steps:

While true:

    -
  1. If timingInfo's - final network-response start time is 0, then set - timingInfo's final network-response start time to +

  2. Set timingInfo's + final network-response start time to the coarsened shared current time given fetchParams's cross-origin isolated capability, immediately after the user agent's HTTP parser receives the first byte of the response (e.g., frame header bytes for @@ -6004,6 +6006,11 @@ optional boolean forceNewConnection (default false), run these steps:

  3. Wait until all the HTTP response headers are transmitted. +

  4. Set timingInfo's + final network-response headers end time to + coarsened shared current time given fetchParams's + cross-origin isolated capability. +

  5. Let status be the HTTP response's status code.

  6. @@ -6017,6 +6024,14 @@ optional boolean forceNewConnection (default false), run these steps:
  7. If request's mode is "websocket" and status is 101, then break. +

  8. If timingInfo's + first interim network-response start time is 0, then set + timingInfo's + first interim network-response start time to + timingInfo's final network-response start time. + +

  9. If status is 101, break. +

  10. If status is 103 and fetchParams's process early hints response is non-null, then queue a fetch task to run fetchParams's @@ -6197,6 +6212,13 @@ optional boolean forceNewConnection (default false), run these steps:

    If one or more bytes have been transmitted from response's message body, then:

      +
    1. If fetchParams's timing info's + response body start time is 0, then set + fetchParams's timing info's + response body start time to the + coarsened shared current time given fetchParams's + cross-origin isolated capability. +

    2. Let bytes be the transmitted bytes.

    3. Let codings be the result of extracting header list values given