From 76ee5f5a9a20916d2195f3dd0e57a3fc5f734bc6 Mon Sep 17 00:00:00 2001 From: Noam Rosenthal Date: Mon, 8 May 2023 11:49:23 +0300 Subject: [PATCH] Add timing information about interim responses See https://github.com/w3c/resource-timing/issues/345 for context. --- fetch.bs | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/fetch.bs b/fetch.bs index 53c6c35b..12cdbe77 100644 --- a/fetch.bs +++ b/fetch.bs @@ -343,6 +343,7 @@ 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)
end time (default 0)
A {{DOMHighResTimeStamp}}. @@ -5995,9 +5996,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 @@ -6015,6 +6015,12 @@ optional boolean forceNewConnection (default false), run these steps: processing we now perform here inline. -->

      +
    1. 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. +

    2. If request's mode is "websocket" and status is 101, then break.