From eab35fc6cd924102284152b95e02567ecc42fd6e Mon Sep 17 00:00:00 2001 From: Noam Rosenthal Date: Tue, 2 Mar 2021 16:51:31 +0200 Subject: [PATCH 01/30] Initial resource timing integration. Created a "fetch timing info" struct to hold the bookkeeping necessary for resource timing. Populated it with some of the required values, leaving some of them for later patches as this is a big undertaking. See https://github.com/w3c/resource-timing/issues/252 --- fetch.bs | 314 ++++++++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 309 insertions(+), 5 deletions(-) diff --git a/fetch.bs b/fetch.bs index 16d9ddf59..7119ed4c5 100644 --- a/fetch.bs +++ b/fetch.bs @@ -186,8 +186,68 @@ lt="authentication entry">authentication entries (for HTTP authentication).
task destination (default null)
Null, a global object, or a parallel queue. +
timing info +
A fetch timing info. +
redirect timing info list (default « ») +
A list of fetch timing info. +

Unsafe shared current time is defined in [[HR-TIME]]. +

Remove this once HR-TIME-3 refs are available. + +

A fetch timing info is a struct used to maintain timing +information later required by the resource timing and navigation timing specs. It has the following +items: +

+
start time (default zero) +
fetch start time (default zero) +
worker start time (default zero) +
request start time (default zero) +
response start time (default zero) +
response end time (default zero) +
redirect start time (default zero) +
redirect end time (default zero) +
A DOMHighResTimeStamp. +
encoded body size (default zero) +
decoded body size (default zero) +
A number. +
connection timing info (default null) +
Null or a connection timing info. +
+ +

A connection timing info is a struct used to maintain timing +information pertaining to the process of obtaining a connection. It has the following +items: +

+
domain lookup start time (default zero) +
domain lookup end time (default zero) +
connection start time (default zero) +
connection end time (default zero) +
secure connection start time (default zero) +
A DOMHighResTimeStamp +
alpn negotiated protocol (default empty string) +
A string. +
+ +

Note that timestamps in this spec are usually unsafe, and are meant to be coarsened +and normalized to a global object prior to being exposed. + +

To clamp connection timing to fetch timing, given connection timing info +timingInfo and DOMHighResTimeStamp defaultStartTime, run these +steps: +

    +

  1. If timingInfo's connection start time is + greater than defaultStartTime, then return timingInfo. + +

  2. Otherwise, return a new connection timing info, with + domain lookup start time set to defaultStartTime, + domain lookup end time set to defaultStartTime, + connection start time set to defaultStartTime, + connection end time set to defaultStartTime, + secure connection start time set to + defaultStartTime, and alpn negotiated protocol + set to timingInfo's alpn negotiated protocol. +

    To queue a fetch task, given an algorithm algorithm, a global object or a parallel queue taskDestination, run these steps: @@ -1922,6 +1982,10 @@ allowed on the resource fetched by looking at the flag of the response returned. the response of a redirect has to be set if it was set for previous responses in the redirect chain, this is also tracked internally using the request's timing allow failed flag. +

    A response has an associated +timing info (Null or a +fetch timing info), which is initially null. +

    A response whose @@ -2139,6 +2203,9 @@ unset or keepalive is false, termi identified by a key (a network partition key), an origin (an origin), and credentials (a boolean). +

    Each connection has an associated connection timing info +timingInfo. +

    To obtain a connection, given a key, origin, credentials, an optional boolean forceNew (default false), an optional boolean http3Only (default @@ -2170,8 +2237,9 @@ false), and an optional boolean dedic

    1. Set connection to the result of establishing an HTTP connection to - origin. [[!HTTP]] [[!HTTP-SEMANTICS]] [[!HTTP-COND]] [[!HTTP-CACHING]] [[!HTTP-AUTH]] - [[!TLS]] + origin, following the requirements for + recording connection timing info. + [[!HTTP]] [[!HTTP-SEMANTICS]] [[!HTTP-COND]] [[!HTTP-CACHING]] [[!HTTP-AUTH]] [[!TLS]]

      If http3Only is true, then establish an HTTP/3 connection. [[!HTTP3]] @@ -2210,6 +2278,89 @@ clearly stipulates that connections are keyed on +

      The requirements for recording connection timing info given a connection +connection and its connection timing info timingInfo, are as +follows: +

        +

      • timingInfo's domain lookup start time + should be the unsafe shared current time immediately before starting the domain + lookup, or beginning retrieval of the information from cache. + +

      • timingInfo's domain lookup end time should + be the unsafe shared current time immediately after finishing the domain lookup, or + retrieving the information from cache. + +

      • timingInfo's connection start time should + be the unsafe shared current time immediately before establishing the connection to + the server or proxy. + +

      • timingInfo's connection end time should be + the unsafe shared current time immediately after establishing the connection to the + server or proxy, as follows: +

          +

        • The returned time must include the time interval to establish the transport + connection, as well as other time intervals such as SOCKS authentication. It + must include the time interval to complete enough of the TLS handshake to + request the resource. + +

        • If the user agent used TLS False Start [[RFC7918]] for this connection, + this interval must not include the time needed to receive the server's + Finished message. + +

        • If the user agent sends the request with early data [[RFC8470]] without + waiting for the full handshare to complete, this interval must not include + the time needed to receive the server's ServerHello message. + +

        • If the user agent waits for full handshake completion to send the + request, this interval includes the full TLS handshake even if other + requests were sent using early data on connection. +

        + +

        Example: Suppose the user agent establishes an HTTP/2 connection + over TLS 1.3 to send a GET request and a POST request. It sends the ClientHello + at time t1 and then sends the GET request with early data. The + POST request is not safe [[HTTP-SEMANTICS]] (section 4.2.1), so the user agent waits + to complete the handshake at time t2 before sending it. Although + both requests used the same connection, the GET request reports a connectEnd + value of t1, while the POST request reports a connectEnd value for + t2. + +

      • If a secure transport is used, timingInfo's + secure connection start time should be the result of calling + unsafe shared current time immmediately before starting the handshake process to + secure connection. [[!TLS]] + +

      • timingInfo's alpn negotiated protocol + should be the connection's ALPN Protocol ID as specified in [[RFC7301]], with the + following caveats: +

          +

        • When a proxy is configured, if a tunnel connection is established then this attribute + must return the ALPN Protocol ID of the tunneled protocol, otherwise it must return the ALPN + Protocol ID of the first hop to the proxy. + +

        • Octets in the ALPN protocol must not be percent-encoded if they are valid token + characters except "%", and when using percent-encoding, uppercase hex digits must be used. + +

        • Formally registered ALPN protocol IDs are documented by + IANA. + +

        • In case the user agent is using an experimental, non-registered protocol, the user + agent must use the ALPN negotiated value if any. If ALPN was not used for protocol + negotiations, the user agent MAY use another descriptive string. + +

          The "h3" ALPN ID is defined for the final version + of the HTTP/3 protocol in the + HTTP/3 + Internet Draft. + +

          Note that alpn negotiated protocol is + intended to identify the network protocol in use for the fetch regardless of how it was + actually negotiated; that is, even if ALPN is not used to negotiate the network protocol, + this attribute still uses the ALPN Protocol IDs to indicate the protocol in use. +

        +
      +

    Network partition keys

    @@ -3353,6 +3504,7 @@ the request.

  3. Let fetchParams be a new fetch params whose request is request, + timing info is a new fetch timing info, process request body is processRequestBody, process request end-of-body is processRequestEndOfBody, process response is processResponse, @@ -3441,6 +3593,10 @@ steps:

  4. Let response be null. +

  5. Set fetchParams's timing info be a new + fetch timing info with its fetch start time set to the + unsafe shared current time. +

  6. If request's local-URLs-only flag is set and request's current URL is not local, then set response to a network error. @@ -3771,6 +3927,75 @@ steps:

+

To Attach timing info, given response +response and fetch params fetchParams, perform the following +steps: +

    +

  1. Let timingInfo be fetchParams's timing info. + +

  2. Let redirectTimingList be fetchParams's + redirect timing info list. + +

  3. Let body be response's body. + +

  4. Set response's timing info to fetchParams's + timing info. + +

  5. If redirectTimingList is not empty, set timingInfo's + redirect start time to redirectTimingList's first item's + fetch start time and + redirect end time to redirectTimingList's last item's + fetch start time. +

+ +

To retrieve timing info, given response response, +perform the following steps: + +

    +

  1. Let timingInfo be response's timing info. + +

  2. If timingInfo is null, return null. + +

  3. Let startTime be timingInfo's + fetch start time. + +

  4. If timingInfo's redirect start time is not zero, + then set startTime to timingInfo's + redirect start time. + +

  5. If response's timing allow passed flag is not set, then + set timingInfo to a new fetch timing info, with its + start time + fetch start time set to startTime. + +

  6. Otherwise, timingInfo's start time to + startTime. + +

  7. Return timingInfo. +

+ +

To finalize and report timing given response +response, a global object global and a DOMString +initiatorType (default "other"), perform the following steps: +

    +

  1. If response's URL list is null or empty, then return. + +

  2. Let originalURL be response's URL list's + first item. + +

  3. Let timingInfo be the result of calling retrieve timing info + for response. + +

  4. If timingInfo is null, then return. + +

  5. Set timingInfo's response end time to the + unsafe shared current time. + +

  6. Set response's timing info to timingInfo. + +

  7. Mark resource timing for + timingInfo, originalURL, initiatorType, and global. +

Scheme fetch

@@ -3894,6 +4119,9 @@ these steps:

  • Let actualResponse be null. +

  • Let timingInfo be fetchParams'stiming + info. +

  • If request's service-workers mode is "all", then: @@ -3901,6 +4129,9 @@ these steps:

  • Let requestForServiceWorker be a clone of request. +

  • Set fetchParams's timing info's + worker start time to the unsafe shared current time. +

  • Set response to the result of invoking handle fetch for requestForServiceWorker. [[!HTML]] [[!SW]] @@ -3908,6 +4139,15 @@ these steps:

    If response is not null, then:

      +

    1. Set fetchParams's timing info's + response start time to the + unsafe shared current time. + +

    2. Set timingInfo's encoded body size and + decoded body size to the result of calling + extract a length from response's + header list. +

    3. If request's body is non-null, then cancel request's body with undefined. @@ -3938,6 +4178,9 @@ these steps:
    +

    Otheriwse, set fetchParams's timing info's + worker start time to zero. +

  • If response is null, then: @@ -4040,6 +4283,14 @@ these steps: +

  • Attach timing info for response and + fetchParams. + +

    Attaching the timing info to a response is what makes it exposed to the web as a + Resource Timing entry later. This step is done here, as resource-timing entries + are available only for HTTP fetchesm, including ones that are handled by service-workers or HTTP + cache, and not for data/blob/file fetches, and are only available after all the CORS checks have + passed for the request.

  • Return response. Typically actualResponse's body's stream is still being enqueued to after returning. @@ -4125,6 +4376,9 @@ run these steps:

    request's body's source's nullity has already been checked. +

  • Append fetchParams's timing info to + fetchParams's redirect timing info list. +

  • Append locationURL to request's URL list. @@ -4428,6 +4682,11 @@ steps. They return a response.

    1. +

      Let timingInfo be fetchParams's timing info. + +

      Set timingInfo's request start time to the + unsafe shared current time. +

      Set storedResponse to the result of selecting a response from the httpCache, possibly needing validation, as per the "Constructing Responses from Caches" @@ -4441,6 +4700,14 @@ steps. They return a response.

        +

      1. Set timingInfo's response start time to the + unsafe shared current time. + +

      2. Set timingInfo's encoded body size and + decoded body size to the result of calling + extract a length from storedResponse's + header list. +

      3. If cache mode is "default", storedResponse is a stale-while-revalidate response, and httpRequest's @@ -4712,6 +4979,8 @@ optional boolean forceNewConnection (default false), run these steps:

      4. Let response be null. +

      5. Let timingInfo be fetchParams's timing info. +

      6. Let httpCache be the result of determining the HTTP cache partition, given httpRequest. @@ -4737,6 +5006,11 @@ optional boolean forceNewConnection (default false), run these steps: includeCredentials, and forceNewConnection. +

      7. Set timingInfo's connection timing info to the + result of calling clamp connection timing to fetch timing with connection's + timingInfo and timingInfo's + fetch start time. +

      8. Run these steps, but abort when the ongoing fetch is terminated: @@ -4750,6 +5024,9 @@ optional boolean forceNewConnection (default false), run these steps: `Transfer-Encoding`/`chunked` to request's header list. +

      9. Set timingInfo's request start time to the + unsafe shared current time. +

      10. Set response to the result of making an HTTP request over connection using request with the following caveats: @@ -4757,6 +5034,11 @@ optional boolean forceNewConnection (default false), run these steps:

        • Follow the relevant requirements from HTTP. [[!HTTP]] [[!HTTP-SEMANTICS]] [[!HTTP-COND]] [[!HTTP-CACHING]] [[!HTTP-AUTH]] +

        • Set timingInfo's response start time to + the unsafe shared current timeimmediately after the user agent's HTTP parser + receives the first byte of the response (e.g. frame header bytes for HTTP/2, or response + status line for HTTP/1.x). +

        • Wait until all the headers are transmitted.

        • @@ -4935,6 +5217,9 @@ optional boolean forceNewConnection (default false), run these steps:

        • Let codings be the result of extracting header list values given `Content-Encoding` and response's header list. +

        • Increase timingInfo's encoded body size + by bytes's length. +

        • Set bytes to the result of handling content codings given codings and bytes. @@ -4942,6 +5227,9 @@ optional boolean forceNewConnection (default false), run these steps:

          This makes the `Content-Length` header unreliable to the extent that it was reliable to begin with. +

        • Increase timingInfo's decoded body size by + bytes's length. +

        • If bytes is failure, then terminate the ongoing fetch. @@ -5784,6 +6072,10 @@ due course. MIME type algorithm which takes no arguments and returns failure or a MIME type. +

          Objects including the {{Body}} interface mixin have an associated +on body consumed (an algorithm which takes no +arguments), initially set to do nothing. +

          Objects including the {{Body}} interface mixin have an associated body (null or a body). @@ -5911,7 +6203,7 @@ the associated steps:

          1. If object is unusable, then return a promise rejected with - a {{TypeError}}. + a {{TypeError}} and call object's on body consumed.

          2. Let promise be a promise resolved with an empty byte sequence. @@ -5922,6 +6214,9 @@ the associated steps:

          3. Let steps be to return the result of package data with the first argument given, type, and object's MIME type. +

          4. Upon fulfillment of promise, call object's + on body consumed. +

          5. Return the result of upon fulfillment of promise given steps.

          @@ -6868,8 +7163,10 @@ method steps are:

        • Return p.

      -
    2. If request's client's - global object is a {{ServiceWorkerGlobalScope}} object, +
    3. Let globalObject be request's client's + global object + +
    4. If globalObject is a {{ServiceWorkerGlobalScope}} object, then set request's service-workers mode to "none".

    5. Let responseObject be null. @@ -6911,9 +7208,16 @@ method steps are:

    6. Set responseObject to the result of creating a {{Response}} object, given response, "immutable", and relevantRealm. +

    7. Set responseObject's on body consumed to calling + finalize and report timing for response, + globalObject and "fetch". +

    8. Resolve p with responseObject.

    +

    If aborted, then finalize and report timing for response, + globalObject and "fetch". +

  • Return p. From 10e38a6406ce1bc2a1bdad09023de4ab151e97a5 Mon Sep 17 00:00:00 2001 From: Noam Rosenthal Date: Wed, 17 Mar 2021 18:42:55 +0200 Subject: [PATCH 02/30] Update fetch.bs Co-authored-by: Anne van Kesteren --- fetch.bs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fetch.bs b/fetch.bs index 7119ed4c5..01d4dad25 100644 --- a/fetch.bs +++ b/fetch.bs @@ -2238,7 +2238,7 @@ false), and an optional boolean dedic

  • Set connection to the result of establishing an HTTP connection to origin, following the requirements for - recording connection timing info. + recording connection timing info given connection. [[!HTTP]] [[!HTTP-SEMANTICS]] [[!HTTP-COND]] [[!HTTP-CACHING]] [[!HTTP-AUTH]] [[!TLS]]

    If http3Only is true, then establish an HTTP/3 connection. [[!HTTP3]] From eef448c1e2ef8756cf8610d9467c30c656e34309 Mon Sep 17 00:00:00 2001 From: Noam Rosenthal Date: Wed, 17 Mar 2021 19:10:35 +0200 Subject: [PATCH 03/30] Export record-connection-info --- fetch.bs | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/fetch.bs b/fetch.bs index 01d4dad25..0fd488b0e 100644 --- a/fetch.bs +++ b/fetch.bs @@ -2278,8 +2278,9 @@ clearly stipulates that connections are keyed on -

    The requirements for recording connection timing info given a connection -connection and its connection timing info timingInfo, are as +

    The requirements for recording connection +timing info given a connection connection and its +connection timing info timingInfo, are as follows:

    • timingInfo's domain lookup start time From 5443e33495e6114f1445161fa0a27a6fd9c6fe75 Mon Sep 17 00:00:00 2001 From: Noam Rosenthal Date: Thu, 18 Mar 2021 15:55:35 +0200 Subject: [PATCH 04/30] Use 'process response done' --- fetch.bs | 105 +++++++++++++++++++++++++++++-------------------------- 1 file changed, 55 insertions(+), 50 deletions(-) diff --git a/fetch.bs b/fetch.bs index 0fd488b0e..1ca8b1fe9 100644 --- a/fetch.bs +++ b/fetch.bs @@ -182,6 +182,7 @@ lt="authentication entry">authentication entries (for HTTP authentication).

      process request end-of-body (default null)
      process response (default null)
      process response end-of-body (default null) +
      process response done (default null)
      Null or an algorithm.
      task destination (default null) @@ -239,7 +240,7 @@ steps:

    • If timingInfo's connection start time is greater than defaultStartTime, then return timingInfo. -

    • Otherwise, return a new connection timing info, with +

    • Return a new connection timing info, with domain lookup start time set to defaultStartTime, domain lookup end time set to defaultStartTime, connection start time set to defaultStartTime, @@ -247,6 +248,7 @@ steps: secure connection start time set to defaultStartTime, and alpn negotiated protocol set to timingInfo's alpn negotiated protocol. +

      To queue a fetch task, given an algorithm algorithm, a global object or a parallel queue taskDestination, run these @@ -2278,9 +2280,8 @@ clearly stipulates that connections are keyed on -

      The requirements for recording connection -timing info given a connection connection and its -connection timing info timingInfo, are as +

      The requirements for recording connection timing info given a connection +connection and its connection timing info timingInfo, are as follows:

      • timingInfo's domain lookup start time @@ -3462,15 +3463,16 @@ optional algorithm processRequestBody, an optional algorithm processRequestEndOfBody, -an optional algorithm processResponse, an -optional algorithm +an optional algorithm processResponse, +an optional algorithm processResponseEndOfBody, -and an optional boolean useParallelQueue (default false), run -the steps below. If given, processRequestBody must be an algorithm accepting an integer -representing the number of bytes transmitted. If given, processRequestEndOfBody must be +an optional algorithm processResponseDone, and an optional +boolean useParallelQueue (default false), run the steps +below. If given, processRequestBody must be an algorithm accepting an integer representing the number of bytes transmitted. If given, processRequestEndOfBody must be an algorithm accepting no arguments. If given, processResponse must be an algorithm accepting a response. If given, processResponseEndOfBody must be an algorithm accepting a response and null, failure, or a byte sequence. +If given, processResponseDone must be an algorithm accepting no arguments.

        An ongoing fetch can be terminated with flag aborted, @@ -3509,7 +3511,8 @@ the request. process request body is processRequestBody, process request end-of-body is processRequestEndOfBody, process response is processResponse, - process response end-of-body is processResponseEndOfBody, and + process response end-of-body is processResponseEndOfBody, + process response done is processResponseDone, and task destination is taskDestination.

      • If request's body is a byte sequence, then set @@ -3920,33 +3923,20 @@ steps: processBody, processBodyError, and fetchParams's task destination. - -

      • Wait for either response's body to be null, or - response's body's stream to be - closed or errored, and then set - request's done flag. - -

        To Attach timing info, given response -response and fetch params fetchParams, perform the following -steps: +

        To finalize response given response response and +fetch params fetchParams, perform the following steps:

          -

        1. Let timingInfo be fetchParams's timing info. +

        2. Let timingInfo be response's timing info -

        3. Let redirectTimingList be fetchParams's - redirect timing info list. - -

        4. Let body be response's body. +

        5. If timingInfo is not null, then set timingInfo's + response end time to the unsafe shared current time. -

        6. Set response's timing info to fetchParams's - timing info. +

        7. Set fetchParams's request's done flag. -

        8. If redirectTimingList is not empty, set timingInfo's - redirect start time to redirectTimingList's first item's - fetch start time and - redirect end time to redirectTimingList's last item's - fetch start time. +

        9. If fetchParams's process response done is not null, + call fetchParams's process response done.

        To retrieve timing info, given response response, @@ -3975,7 +3965,7 @@ perform the following steps:

      • Return timingInfo. -

        To finalize and report timing given response +

        To finalize and report timing given response response, a global object global and a DOMString initiatorType (default "other"), perform the following steps:

          @@ -4134,7 +4124,8 @@ these steps: worker start time to the unsafe shared current time.

        1. Set response to the result of invoking handle fetch for - requestForServiceWorker. [[!HTML]] [[!SW]] + requestForServiceWorker and fetchParams + process response done. [[!HTML]] [[!SW]]

        2. If response is not null, then: @@ -4284,8 +4275,27 @@ these steps:

        -

      • Attach timing info for response and - fetchParams. +

      • Let redirectTimingList be fetchParams's + redirect timing info list. + +

      • If redirectTimingList is not empty, set timingInfo's + redirect start time to redirectTimingList's first item's + fetch start time and + redirect end time to redirectTimingList's last item's + fetch start time. + +

      • Set response's timing info to timingInfo. + +

        Attaching the timing info to a response is what makes it exposed to the web as a + Resource Timing entry later. This step is done here, as resource-timing entries + are available only for HTTP fetches, including ones that are handled by service-workers or HTTP + cache, and not for data/blob/file fetches, and are only available after all the CORS checks have + passed for the request. + +

      • Return response. Typically + actualResponse's body's + stream is still being enqueued to after returning. +

        Attaching the timing info to a response is what makes it exposed to the web as a Resource Timing entry later. This step is done here, as resource-timing entries @@ -5254,6 +5264,8 @@ optional boolean forceNewConnection (default false), run these steps:

        If aborted, then:

          +
        1. Finalize response for response and fetchParams. +

        2. Let aborted be the termination's aborted flag.

        3. @@ -6073,10 +6085,6 @@ due course. MIME type algorithm which takes no arguments and returns failure or a MIME type. -

          Objects including the {{Body}} interface mixin have an associated -on body consumed (an algorithm which takes no -arguments), initially set to do nothing. -

          Objects including the {{Body}} interface mixin have an associated body (null or a body). @@ -6204,7 +6212,7 @@ the associated steps:

          1. If object is unusable, then return a promise rejected with - a {{TypeError}} and call object's on body consumed. + a {{TypeError}}.

          2. Let promise be a promise resolved with an empty byte sequence. @@ -6215,9 +6223,6 @@ the associated steps:

          3. Let steps be to return the result of package data with the first argument given, type, and object's MIME type. -

          4. Upon fulfillment of promise, call object's - on body consumed. -

          5. Return the result of upon fulfillment of promise given steps.

          @@ -7192,9 +7197,13 @@ method steps are:

        4. Terminate the ongoing fetch with the aborted flag set.

        +

      • Let handleFetchDone be to finalize and report timing with + response, globalObject, and "fetch". +

      • -

        Fetch request with processResponse given - response being these substeps: +

        Fetch request with processResponseDone set to + handleFetchDone, and processResponse given response + being these substeps:

        1. If locallyAborted is true, terminate these substeps. @@ -7209,14 +7218,10 @@ method steps are:

        2. Set responseObject to the result of creating a {{Response}} object, given response, "immutable", and relevantRealm. -

        3. Set responseObject's on body consumed to calling - finalize and report timing for response, - globalObject and "fetch". -

        4. Resolve p with responseObject.

        -

        If aborted, then finalize and report timing for response, +

        If aborted, then finalize and report timing for response, globalObject and "fetch".

      • Return p. From b3596b650db8c656a9795e7456a51b0c85a8c694 Mon Sep 17 00:00:00 2001 From: Noam Rosenthal Date: Thu, 18 Mar 2021 16:24:18 +0200 Subject: [PATCH 05/30] Inline 'retrieve' --- fetch.bs | 44 ++++++++++++++++++-------------------------- 1 file changed, 18 insertions(+), 26 deletions(-) diff --git a/fetch.bs b/fetch.bs index 1ca8b1fe9..2a60c768c 100644 --- a/fetch.bs +++ b/fetch.bs @@ -3939,14 +3939,26 @@ steps: call fetchParams's process response done. -

        To retrieve timing info, given response response, -perform the following steps: - +

        To finalize and report timing given response +response, a global object global and a DOMString +initiatorType (default "other"), perform the following steps:

          +

        1. If response's URL list is null or empty, then return. + +

        2. Let originalURL be response's URL list's + first item. +

        3. Let timingInfo be response's timing info. -

        4. If timingInfo is null, return null. +

            +

          1. Otherwise, timingInfo's start time to + startTime. +

          2. Return timingInfo. +

          + +

        5. If timingInfo is null, then return. +

        6. Let startTime be timingInfo's fetch start time. @@ -3956,28 +3968,8 @@ perform the following steps:

        7. If response's timing allow passed flag is not set, then set timingInfo to a new fetch timing info, with its - start time - fetch start time set to startTime. - -

        8. Otherwise, timingInfo's start time to - startTime. - -

        9. Return timingInfo. -

        - -

        To finalize and report timing given response -response, a global object global and a DOMString -initiatorType (default "other"), perform the following steps: -

          -

        1. If response's URL list is null or empty, then return. - -

        2. Let originalURL be response's URL list's - first item. - -

        3. Let timingInfo be the result of calling retrieve timing info - for response. - -

        4. If timingInfo is null, then return. + start time and fetch start time set + to startTime.

        5. Set timingInfo's response end time to the unsafe shared current time. From ce450d1116af480afbafc455d2ca8de1b2699669 Mon Sep 17 00:00:00 2001 From: Noam Rosenthal Date: Fri, 19 Mar 2021 12:29:14 +0200 Subject: [PATCH 06/30] nits --- fetch.bs | 12 ++---------- 1 file changed, 2 insertions(+), 10 deletions(-) diff --git a/fetch.bs b/fetch.bs index 2a60c768c..5a012c858 100644 --- a/fetch.bs +++ b/fetch.bs @@ -3950,15 +3950,8 @@ steps:

        6. Let timingInfo be response's timing info. -

            -

          1. Otherwise, timingInfo's start time to - startTime. - -

          2. Return timingInfo. -

          -

        7. If timingInfo is null, then return. - +

        8. Let startTime be timingInfo's fetch start time. @@ -4116,8 +4109,7 @@ these steps: worker start time to the unsafe shared current time.

        9. Set response to the result of invoking handle fetch for - requestForServiceWorker and fetchParams - process response done. [[!HTML]] [[!SW]] + requestForServiceWorker. [[!HTML]] [[!SW]]

        10. If response is not null, then: From d5e66beaeb0baed3c1754a3cc2cf206b16bdb892 Mon Sep 17 00:00:00 2001 From: Noam Rosenthal Date: Mon, 22 Mar 2021 16:00:07 +0200 Subject: [PATCH 07/30] More PR nits --- fetch.bs | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/fetch.bs b/fetch.bs index 5a012c858..444602650 100644 --- a/fetch.bs +++ b/fetch.bs @@ -5240,7 +5240,8 @@ optional boolean forceNewConnection (default false), run these steps:

        11. Otherwise, if the bytes transmission for response's message body is done normally and stream is readable, then - close stream and abort these in-parallel steps. + close stream, Finalize response for + response and fetchParams, and abort these in-parallel steps.

        @@ -7205,9 +7206,6 @@ method steps are:

      • Resolve p with responseObject. -

        If aborted, then finalize and report timing for response, - globalObject and "fetch". -

      • Return p. From afd13c82aafd7cb8287475db2901b2f0be94cc02 Mon Sep 17 00:00:00 2001 From: Noam Rosenthal Date: Mon, 22 Mar 2021 16:06:01 +0200 Subject: [PATCH 08/30] Queue --- fetch.bs | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/fetch.bs b/fetch.bs index 444602650..32e458069 100644 --- a/fetch.bs +++ b/fetch.bs @@ -3936,7 +3936,9 @@ steps:

      • Set fetchParams's request's done flag.

      • If fetchParams's process response done is not null, - call fetchParams's process response done. + then queue a fetch task given fetchParams's + process response done and fetchParams's + task destination.

        To finalize and report timing given response From 37a88237103d7fa11b5eb6d66d89e7bd3dcab551 Mon Sep 17 00:00:00 2001 From: Noam Rosenthal Date: Mon, 22 Mar 2021 16:08:31 +0200 Subject: [PATCH 09/30] Decapitalize --- fetch.bs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fetch.bs b/fetch.bs index 32e458069..0dff061df 100644 --- a/fetch.bs +++ b/fetch.bs @@ -5242,7 +5242,7 @@ optional boolean forceNewConnection (default false), run these steps:

      • Otherwise, if the bytes transmission for response's message body is done normally and stream is readable, then - close stream, Finalize response for + close stream, finalize response for response and fetchParams, and abort these in-parallel steps. From 262fe0035e6cda2bbcb07be03e335d71b89f0dda Mon Sep 17 00:00:00 2001 From: Noam Rosenthal Date: Mon, 22 Mar 2021 16:38:04 +0200 Subject: [PATCH 10/30] Attempt to fix build --- fetch.bs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fetch.bs b/fetch.bs index 0dff061df..0de330ac9 100644 --- a/fetch.bs +++ b/fetch.bs @@ -3933,7 +3933,7 @@ steps:

      • If timingInfo is not null, then set timingInfo's response end time to the unsafe shared current time. -

      • Set fetchParams's request's done flag. +

      • Set fetchParams's request's done flag.

      • If fetchParams's process response done is not null, then queue a fetch task given fetchParams's From aafbb7691a6a822652e71a3b92b1967335b9e097 Mon Sep 17 00:00:00 2001 From: Noam Rosenthal Date: Mon, 22 Mar 2021 16:43:44 +0200 Subject: [PATCH 11/30] Attempt to fix build --- fetch.bs | 10 ---------- 1 file changed, 10 deletions(-) diff --git a/fetch.bs b/fetch.bs index 0de330ac9..9d2e7fa8e 100644 --- a/fetch.bs +++ b/fetch.bs @@ -4283,16 +4283,6 @@ these steps: stream is still being enqueued to after returning. -

        Attaching the timing info to a response is what makes it exposed to the web as a - Resource Timing entry later. This step is done here, as resource-timing entries - are available only for HTTP fetchesm, including ones that are handled by service-workers or HTTP - cache, and not for data/blob/file fetches, and are only available after all the CORS checks have - passed for the request. -

      • Return response. Typically - actualResponse's body's - stream is still being enqueued to after returning. - -

        HTTP-redirect fetch

        From 3ea8d88ccba3fdefeab03636798c424e25a03608 Mon Sep 17 00:00:00 2001 From: Noam Rosenthal Date: Mon, 22 Mar 2021 16:57:06 +0200 Subject: [PATCH 12/30] Attempt to fix build --- fetch.bs | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fetch.bs b/fetch.bs index 9d2e7fa8e..21617bd4e 100644 --- a/fetch.bs +++ b/fetch.bs @@ -7147,7 +7147,7 @@ method steps are:
      • Let globalObject be request's client's - global object + global object.
      • If globalObject is a {{ServiceWorkerGlobalScope}} object, then set request's service-workers mode to "none". @@ -7178,7 +7178,7 @@ method steps are: response, globalObject, and "fetch".
      • -

        Fetch request with processResponseDone set to +

        Fetch request with processResponseDone set to handleFetchDone, and processResponse given response being these substeps: From c6a517361dc0adbfbb7d6ace5cbfafbf7dab453d Mon Sep 17 00:00:00 2001 From: Noam Rosenthal Date: Mon, 22 Mar 2021 18:19:57 +0200 Subject: [PATCH 13/30] Fix nit --- fetch.bs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fetch.bs b/fetch.bs index 21617bd4e..98504e998 100644 --- a/fetch.bs +++ b/fetch.bs @@ -197,7 +197,7 @@ lt="authentication entry">authentication entries (for HTTP authentication).

        Remove this once HR-TIME-3 refs are available.

        A fetch timing info is a struct used to maintain timing -information later required by the resource timing and navigation timing specs. It has the following +information required by the resource timing and navigation timing specs. It has the following items:

        start time (default zero) From ffdc8948fe43cf83f9e043181e84a58e52200d2e Mon Sep 17 00:00:00 2001 From: Noam Rosenthal Date: Mon, 22 Mar 2021 18:38:31 +0200 Subject: [PATCH 14/30] Remove unsafe shared current time note --- fetch.bs | 3 --- 1 file changed, 3 deletions(-) diff --git a/fetch.bs b/fetch.bs index 98504e998..a0dfed07c 100644 --- a/fetch.bs +++ b/fetch.bs @@ -193,9 +193,6 @@ lt="authentication entry">authentication entries (for HTTP authentication).
        A list of fetch timing info.
        -

        Unsafe shared current time is defined in [[HR-TIME]]. -

        Remove this once HR-TIME-3 refs are available. -

        A fetch timing info is a struct used to maintain timing information required by the resource timing and navigation timing specs. It has the following items: From 00a20e0a59a04d197c604242b54140fed54db7a0 Mon Sep 17 00:00:00 2001 From: Noam Rosenthal Date: Mon, 22 Mar 2021 19:06:40 +0200 Subject: [PATCH 15/30] Clarify connection timing info reuse --- fetch.bs | 72 ++++++++++++++++++++++++++++++-------------------------- 1 file changed, 38 insertions(+), 34 deletions(-) diff --git a/fetch.bs b/fetch.bs index a0dfed07c..bf755f86b 100644 --- a/fetch.bs +++ b/fetch.bs @@ -2324,41 +2324,45 @@ follows: value of t1, while the POST request reports a connectEnd value for t2. -

      • If a secure transport is used, timingInfo's - secure connection start time should be the result of calling - unsafe shared current time immmediately before starting the handshake process to - secure connection. [[!TLS]] - -

      • timingInfo's alpn negotiated protocol - should be the connection's ALPN Protocol ID as specified in [[RFC7301]], with the - following caveats: -

          -

        • When a proxy is configured, if a tunnel connection is established then this attribute - must return the ALPN Protocol ID of the tunneled protocol, otherwise it must return the ALPN - Protocol ID of the first hop to the proxy. - -

        • Octets in the ALPN protocol must not be percent-encoded if they are valid token - characters except "%", and when using percent-encoding, uppercase hex digits must be used. - -

        • Formally registered ALPN protocol IDs are documented by - IANA. - -

        • In case the user agent is using an experimental, non-registered protocol, the user - agent must use the ALPN negotiated value if any. If ALPN was not used for protocol - negotiations, the user agent MAY use another descriptive string. - -

          The "h3" ALPN ID is defined for the final version - of the HTTP/3 protocol in the - HTTP/3 - Internet Draft. - -

          Note that alpn negotiated protocol is - intended to identify the network protocol in use for the fetch regardless of how it was - actually negotiated; that is, even if ALPN is not used to negotiate the network protocol, - this attribute still uses the ALPN Protocol IDs to indicate the protocol in use. -

        +

      • If a secure transport is used, timingInfo's + secure connection start time should be the result of calling + unsafe shared current time immmediately before starting the handshake process to + secure connection. [[!TLS]] + +

      • timingInfo's alpn negotiated protocol + should be the connection's ALPN Protocol ID as specified in [[RFC7301]], with the + following caveats: +

          +

        • When a proxy is configured, if a tunnel connection is established then this attribute + must return the ALPN Protocol ID of the tunneled protocol, otherwise it must return the ALPN + Protocol ID of the first hop to the proxy. + +

        • Octets in the ALPN protocol must not be percent-encoded if they are valid token + characters except "%", and when using percent-encoding, uppercase hex digits must be used. + +

        • Formally registered ALPN protocol IDs are documented by + IANA. + +

        • In case the user agent is using an experimental, non-registered protocol, the user + agent must use the ALPN negotiated value if any. If ALPN was not used for protocol + negotiations, the user agent MAY use another descriptive string. + +

          The "h3" ALPN ID is defined for the final version + of the HTTP/3 protocol in the + HTTP/3 + Internet Draft. + +

          Note that alpn negotiated protocol is + intended to identify the network protocol in use for the fetch regardless of how it was + actually negotiated; that is, even if ALPN is not used to negotiate the network protocol, + this attribute still uses the ALPN Protocol IDs to indicate the protocol in use.

        + +

        The timingInfo for the connection might be saved in the + connection pool, and later retrieved alongside the connection if the connection is reused. + The clamp connection timing to fetch timing algorithm ensures that details of reused + connections are not exposed.

        Network partition keys

        From 69ee50cf0e46b3cae7be052e757e2db570688430 Mon Sep 17 00:00:00 2001 From: Noam Rosenthal Date: Tue, 23 Mar 2021 08:47:45 +0200 Subject: [PATCH 16/30] Remove cached body size handling --- fetch.bs | 31 ++++++++----------------------- 1 file changed, 8 insertions(+), 23 deletions(-) diff --git a/fetch.bs b/fetch.bs index bf755f86b..744a5b294 100644 --- a/fetch.bs +++ b/fetch.bs @@ -4108,8 +4108,7 @@ these steps:

      • Let requestForServiceWorker be a clone of request. -

      • Set fetchParams's timing info's - worker start time to the unsafe shared current time. +

      • Let workerStartTime be the unsafe shared current time.

      • Set response to the result of invoking handle fetch for requestForServiceWorker. [[!HTML]] [[!SW]] @@ -4119,13 +4118,13 @@ these steps:

        1. Set fetchParams's timing info's - response start time to the - unsafe shared current time. + worker start time to workerStartTime. -

        2. Set timingInfo's encoded body size and - decoded body size to the result of calling - extract a length from response's - header list. +

          If the response is cached, the current timing info's + encoded body size, + decoded body size, + request start time, + and response start time will remain zero.

        3. If request's body is non-null, then cancel request's body with undefined. @@ -4157,9 +4156,6 @@ these steps:
        -

        Otheriwse, set fetchParams's timing info's - worker start time to zero. -

      • If response is null, then: @@ -4672,9 +4668,6 @@ steps. They return a response.

      • Let timingInfo be fetchParams's timing info. -

        Set timingInfo's request start time to the - unsafe shared current time. -

        Set storedResponse to the result of selecting a response from the httpCache, possibly needing validation, as per the "Constructing Responses from Caches" @@ -4688,14 +4681,6 @@ steps. They return a response.

          -

        1. Set timingInfo's response start time to the - unsafe shared current time. - -

        2. Set timingInfo's encoded body size and - decoded body size to the result of calling - extract a length from storedResponse's - header list. -

        3. If cache mode is "default", storedResponse is a stale-while-revalidate response, and httpRequest's @@ -5023,7 +5008,7 @@ optional boolean forceNewConnection (default false), run these steps:

        4. Follow the relevant requirements from HTTP. [[!HTTP]] [[!HTTP-SEMANTICS]] [[!HTTP-COND]] [[!HTTP-CACHING]] [[!HTTP-AUTH]]

        5. Set timingInfo's response start time to - the unsafe shared current timeimmediately after the user agent's HTTP parser + the unsafe shared current time immediately after the user agent's HTTP parser receives the first byte of the response (e.g. frame header bytes for HTTP/2, or response status line for HTTP/1.x). From d0c2d5646036a97da932f1e4ecba864e5e0ae39d Mon Sep 17 00:00:00 2001 From: Noam Rosenthal Date: Tue, 23 Mar 2021 09:59:13 +0200 Subject: [PATCH 17/30] Set encoded/decoded body size from stored response --- fetch.bs | 26 +++++++++++++++++++++----- 1 file changed, 21 insertions(+), 5 deletions(-) diff --git a/fetch.bs b/fetch.bs index 744a5b294..f33df07f7 100644 --- a/fetch.bs +++ b/fetch.bs @@ -247,6 +247,20 @@ steps: set to timingInfo's alpn negotiated protocol.

        +

        To update timing info from stored response, given connection timing info +timingInfo and response response, perform the following steps: +

          +

        1. Let storedTimingInfo be response's timing info. + +

        2. If storedTimingInfo is null, then return. + +

        3. Set timingInfo's encoded body size to + storedTimingInfo's encoded body size. + +

        4. Set timingInfo's decoded body size to + storedTimingInfo's decoded body size. +

        +

        To queue a fetch task, given an algorithm algorithm, a global object or a parallel queue taskDestination, run these steps: @@ -4120,11 +4134,8 @@ these steps:

      • Set fetchParams's timing info's worker start time to workerStartTime. -

        If the response is cached, the current timing info's - encoded body size, - decoded body size, - request start time, - and response start time will remain zero. +

      • Update timing info from stored response for fetchParams's + timing info anf response.

      • If request's body is non-null, then cancel request's body with undefined. @@ -4792,6 +4803,8 @@ steps. They return a response.

      • Set response to storedResponse. +

      • Update timing info from stored response for fetchParams's + timing info anf response.

      • @@ -4807,6 +4820,9 @@ steps. They return a response.

        If forwardResponse is a network error, this effectively caches the network error, which is sometimes known as "negative caching". + +

        The associated timing info is stored in the cache + alongside the response. From 1e82d9f3b7c67e3cf1e8f330dfeee9bf6f67d4bc Mon Sep 17 00:00:00 2001 From: Noam Rosenthal Date: Tue, 23 Mar 2021 10:02:17 +0200 Subject: [PATCH 18/30] Fix typo --- fetch.bs | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fetch.bs b/fetch.bs index f33df07f7..c65db51d7 100644 --- a/fetch.bs +++ b/fetch.bs @@ -4135,7 +4135,7 @@ these steps: worker start time to workerStartTime.

      • Update timing info from stored response for fetchParams's - timing info anf response. + timing info and response.

      • If request's body is non-null, then cancel request's body with undefined. @@ -4804,7 +4804,7 @@ steps. They return a response.

      • Set response to storedResponse.

      • Update timing info from stored response for fetchParams's - timing info anf response. + timing info and response.

      • From cb1fb7ce48ac4003c9646528acb952e8aed3c9d6 Mon Sep 17 00:00:00 2001 From: Noam Rosenthal Date: Tue, 23 Mar 2021 11:49:03 +0200 Subject: [PATCH 19/30] Fix nit --- fetch.bs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fetch.bs b/fetch.bs index c65db51d7..c1aef7ad3 100644 --- a/fetch.bs +++ b/fetch.bs @@ -4112,7 +4112,7 @@ these steps:

      • Let actualResponse be null. -

      • Let timingInfo be fetchParams'stiming +

      • Let timingInfo be fetchParams's timing info.

      • From 699875f4b24dd9849324819e6b45753fb8c34a0d Mon Sep 17 00:00:00 2001 From: Noam Rosenthal Date: Tue, 23 Mar 2021 15:12:09 +0200 Subject: [PATCH 20/30] Added a note about 10x --- fetch.bs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fetch.bs b/fetch.bs index c1aef7ad3..02a78ea23 100644 --- a/fetch.bs +++ b/fetch.bs @@ -5026,7 +5026,7 @@ optional boolean forceNewConnection (default false), run these steps:

      • Set timingInfo's response start time to the unsafe shared current time immediately after the user agent's HTTP parser receives the first byte of the response (e.g. frame header bytes for HTTP/2, or response - status line for HTTP/1.x). + status line for HTTP/1.x), regardless of the response's status code.

      • Wait until all the headers are transmitted. From dddf4e00556857ef6a9ead9db09c1e5a15b0e373 Mon Sep 17 00:00:00 2001 From: Anne van Kesteren Date: Tue, 23 Mar 2021 18:33:14 +0100 Subject: [PATCH 21/30] nits + TODOs --- fetch.bs | 279 +++++++++++++++++++++++++++++-------------------------- 1 file changed, 149 insertions(+), 130 deletions(-) diff --git a/fetch.bs b/fetch.bs index 02a78ea23..58137a2f1 100644 --- a/fetch.bs +++ b/fetch.bs @@ -187,28 +187,33 @@ lt="authentication entry">authentication entries (for HTTP authentication).

        task destination (default null)
        Null, a global object, or a parallel queue. +
        timing info
        A fetch timing info. +
        redirect timing info list (default « ») -
        A list of fetch timing info. +
        A list of 0 or more fetch timing info.

        A fetch timing info is a struct used to maintain timing information required by the resource timing and navigation timing specs. It has the following items: +

        -
        start time (default zero) -
        fetch start time (default zero) -
        worker start time (default zero) -
        request start time (default zero) -
        response start time (default zero) -
        response end time (default zero) -
        redirect start time (default zero) -
        redirect end time (default zero) +
        start time (default 0) +
        fetch start time (default 0) +
        worker start time (default 0) +
        request start time (default 0) +
        response start time (default 0) +
        response end time (default 0) +
        redirect start time (default 0) +
        redirect end time (default 0)
        A DOMHighResTimeStamp. -
        encoded body size (default zero) -
        decoded body size (default zero) + +
        encoded body size (default 0) +
        decoded body size (default 0)
        A number. +
        connection timing info (default null)
        Null or a connection timing info.
        @@ -216,13 +221,15 @@ information required by the resource timing and navigation timing specs. It has

        A connection timing info is a struct used to maintain timing information pertaining to the process of obtaining a connection. It has the following items: +

        -
        domain lookup start time (default zero) -
        domain lookup end time (default zero) -
        connection start time (default zero) -
        connection end time (default zero) -
        secure connection start time (default zero) +
        domain lookup start time (default 0) +
        domain lookup end time (default 0) +
        connection start time (default 0) +
        connection end time (default 0) +
        secure connection start time (default 0)
        A DOMHighResTimeStamp +
        alpn negotiated protocol (default empty string)
        A string.
        @@ -230,9 +237,10 @@ information pertaining to the process of obtaining a connection. It has the foll

        Note that timestamps in this spec are usually unsafe, and are meant to be coarsened and normalized to a global object prior to being exposed. -

        To clamp connection timing to fetch timing, given connection timing info -timingInfo and DOMHighResTimeStamp defaultStartTime, run these -steps: +

        To clamp connection timing to fetch timing, given a +connection timing info timingInfo and a +DOMHighResTimeStamp defaultStartTime, run these steps: +

        1. If timingInfo's connection start time is greater than defaultStartTime, then return timingInfo. @@ -247,8 +255,10 @@ steps: set to timingInfo's alpn negotiated protocol.

        -

        To update timing info from stored response, given connection timing info -timingInfo and response response, perform the following steps: +

        To update timing info from stored response, given a +connection timing info timingInfo and a response +response, perform the following steps: +

        1. Let storedTimingInfo be response's timing info. @@ -1996,7 +2006,7 @@ the response of a redirect has to be set if it was set for previous responses in this is also tracked internally using the request's timing allow failed flag.

          A response has an associated -timing info (Null or a +timing info (null or a fetch timing info), which is initially null.

          @@ -2249,9 +2259,9 @@ false), and an optional boolean dedic
          1. -

            Set connection to the result of establishing an HTTP connection to - origin, following the requirements for - recording connection timing info given connection. +

            Set connection to a new connection. + Record connection timing info given connection and use + connection to establish an HTTP connection to origin. [[!HTTP]] [[!HTTP-SEMANTICS]] [[!HTTP-COND]] [[!HTTP-CACHING]] [[!HTTP-AUTH]] [[!TLS]]

            If http3Only is true, then establish an HTTP/3 connection. [[!HTTP3]] @@ -2291,9 +2301,10 @@ clearly stipulates that connections are keyed on -

            The requirements for recording connection timing info given a connection -connection and its connection timing info timingInfo, are as -follows: +

            To record connection timing info given a connection +connection, let timingInfo be connection's +connection timing info and observe these requirements: +

            • timingInfo's domain lookup start time should be the unsafe shared current time immediately before starting the domain @@ -2307,76 +2318,77 @@ follows: be the unsafe shared current time immediately before establishing the connection to the server or proxy. -

            • timingInfo's connection end time should be - the unsafe shared current time immediately after establishing the connection to the - server or proxy, as follows: -

                -

              • The returned time must include the time interval to establish the transport - connection, as well as other time intervals such as SOCKS authentication. It - must include the time interval to complete enough of the TLS handshake to - request the resource. - -

              • If the user agent used TLS False Start [[RFC7918]] for this connection, - this interval must not include the time needed to receive the server's - Finished message. - -

              • If the user agent sends the request with early data [[RFC8470]] without - waiting for the full handshare to complete, this interval must not include - the time needed to receive the server's ServerHello message. - -

              • If the user agent waits for full handshake completion to send the - request, this interval includes the full TLS handshake even if other - requests were sent using early data on connection. -

              - -

              Example: Suppose the user agent establishes an HTTP/2 connection - over TLS 1.3 to send a GET request and a POST request. It sends the ClientHello - at time t1 and then sends the GET request with early data. The - POST request is not safe [[HTTP-SEMANTICS]] (section 4.2.1), so the user agent waits - to complete the handshake at time t2 before sending it. Although - both requests used the same connection, the GET request reports a connectEnd - value of t1, while the POST request reports a connectEnd value for - t2. +

            • +

              timingInfo's connection end time should be the + unsafe shared current time immediately after establishing the connection to the + server or proxy, as follows: + +

                +

              • The returned time must include the time interval to establish the transport connection, as + well as other time intervals such as SOCKS authentication. It must include the time interval to + complete enough of the TLS handshake to request the resource. + +

              • If the user agent used TLS False Start for this connection, this interval must not include + the time needed to receive the server's Finished message. [[RFC7918]] + +

              • If the user agent sends the request with early data without waiting for the full handshare + to complete, this interval must not include the time needed to receive the server's ServerHello + message. [[RFC8470]] + +

              • If the user agent waits for full handshake completion to send the request, this interval + includes the full TLS handshake even if other requests were sent using early data on + connection. +

              + +

              Suppose the user agent establishes an HTTP/2 connection over TLS 1.3 to send a + GET request and a POST request. It sends the ClientHello at time + t1 and then sends the GET request with early data. The POST + request is not safe ([[HTTP-SEMANTICS]], section 4.2.1), so the user agent waits to complete the + handshake at time t2 before sending it. Although both requests used the same + connection, the GET request reports a connection end time of t1, while the + POST request reports t2.

            • If a secure transport is used, timingInfo's secure connection start time should be the result of calling unsafe shared current time immmediately before starting the handshake process to secure connection. [[!TLS]] -

            • timingInfo's alpn negotiated protocol - should be the connection's ALPN Protocol ID as specified in [[RFC7301]], with the - following caveats: -

                -

              • When a proxy is configured, if a tunnel connection is established then this attribute - must return the ALPN Protocol ID of the tunneled protocol, otherwise it must return the ALPN - Protocol ID of the first hop to the proxy. - -

              • Octets in the ALPN protocol must not be percent-encoded if they are valid token - characters except "%", and when using percent-encoding, uppercase hex digits must be used. - -

              • Formally registered ALPN protocol IDs are documented by - IANA. - -

              • In case the user agent is using an experimental, non-registered protocol, the user - agent must use the ALPN negotiated value if any. If ALPN was not used for protocol - negotiations, the user agent MAY use another descriptive string. - -

                The "h3" ALPN ID is defined for the final version - of the HTTP/3 protocol in the - HTTP/3 - Internet Draft. - -

                Note that alpn negotiated protocol is - intended to identify the network protocol in use for the fetch regardless of how it was - actually negotiated; that is, even if ALPN is not used to negotiate the network protocol, - this attribute still uses the ALPN Protocol IDs to indicate the protocol in use. -

              - -

              The timingInfo for the connection might be saved in the - connection pool, and later retrieved alongside the connection if the connection is reused. - The clamp connection timing to fetch timing algorithm ensures that details of reused - connections are not exposed. +

            • +

              timingInfo's alpn negotiated protocol should be + the connection's ALPN Protocol ID, with the following caveats: [[RFC7301]] + + +

                +

              • When a proxy is configured, if a tunnel connection is established then this must be the + ALPN Protocol ID of the tunneled protocol, otherwise it must be the ALPN Protocol ID of the first + hop to the proxy. + +

              • Octets in the ALPN Protocol ID must not be percent-encoded if they are valid token + characters except "%", and when using percent-encoding, uppercase hex digits must be used. + + +

              • Formally registered ALPN Protocol IDs are documented by + IANA. + + +

              • +

                In case the user agent is using an experimental, non-registered protocol, the user agent must + use the used ALPN Protocol ID, if any. If ALPN was not used for protocol negotiations, the user + agent may use another descriptive string. + +

                The "h3" ALPN Protocol ID is defined for the final version of the + HTTP/3 protocol in the + HTTP/3 Internet Draft. + +

                connection's + alpn negotiated protocol is intended to identify the network + protocol in use regardless of how it was actually negotiated; that is, even if ALPN is not used + to negotiate the network protocol, this is the ALPN Protocol IDs that indicates the protocol in + use. +

              + +

              The clamp connection timing to fetch timing algorithm ensures that + details of reused connections are not exposed.

          Network partition keys

          @@ -3483,11 +3495,12 @@ an optional algorithm processResponseEndOfBody, an optional algorithm processResponseDone, and an optional boolean useParallelQueue (default false), run the steps -below. If given, processRequestBody must be an algorithm accepting an integer representing the number of bytes transmitted. If given, processRequestEndOfBody must be +below. If given, processRequestBody must be an algorithm accepting an integer +representing the number of bytes transmitted. If given, processRequestEndOfBody must be an algorithm accepting no arguments. If given, processResponse must be an algorithm accepting a response. If given, processResponseEndOfBody must be an -algorithm accepting a response and null, failure, or a byte sequence. -If given, processResponseDone must be an algorithm accepting no arguments. +algorithm accepting a response and null, failure, or a byte sequence. If +given, processResponseDone must be an algorithm accepting no arguments.

          An ongoing fetch can be terminated with flag aborted, @@ -3612,9 +3625,8 @@ steps:

        2. Let response be null. -

        3. Set fetchParams's timing info be a new - fetch timing info with its fetch start time set to the - unsafe shared current time. +

        4. Set fetchParams's timing info's + fetch start time to the unsafe shared current time.

        5. If request's local-URLs-only flag is set and request's current URL is not local, then set response to a @@ -3940,15 +3952,17 @@ steps:

        -

        To finalize response given response response and -fetch params fetchParams, perform the following steps: +

        To finalize response given a fetch params fetchParams and a +response response, run these steps: +

          -

        1. Let timingInfo be response's timing info +

        2. Let timingInfo be response's timing info.

        3. If timingInfo is not null, then set timingInfo's response end time to the unsafe shared current time. -

        4. Set fetchParams's request's done flag. +

        5. Set fetchParams's request's + done flag.

        6. If fetchParams's process response done is not null, then queue a fetch task given fetchParams's @@ -3956,14 +3970,15 @@ steps: task destination.

        -

        To finalize and report timing given response -response, a global object global and a DOMString -initiatorType (default "other"), perform the following steps: +

        To finalize and report timing given a response +response, a global object global, and a string +initiatorType (default "other"), run these steps: +

          -

        1. If response's URL list is null or empty, then return. +

        2. If response's URL list is null or + empty, then return. -

        3. Let originalURL be response's URL list's - first item. +

        4. Let originalURL be response's URL list[0].

        5. Let timingInfo be response's timing info. @@ -3972,12 +3987,12 @@ steps:

        6. Let startTime be timingInfo's fetch start time. -

        7. If timingInfo's redirect start time is not zero, - then set startTime to timingInfo's +

        8. If timingInfo's redirect start time is not 0, then + set startTime to timingInfo's redirect start time. -

        9. If response's timing allow passed flag is not set, then - set timingInfo to a new fetch timing info, with its +

        10. If response's timing allow passed flag is not set, then set + timingInfo to a new fetch timing info, with its start time and fetch start time set to startTime. @@ -3988,8 +4003,10 @@ steps:

        11. Mark resource timing for timingInfo, originalURL, initiatorType, and global. +

        +

        Scheme fetch

        To scheme fetch, given a @@ -4112,8 +4129,7 @@ these steps:

      • Let actualResponse be null. -

      • Let timingInfo be fetchParams's timing - info. +

      • Let timingInfo be fetchParams's timing info.

      • If request's service-workers mode is "all", then: @@ -4123,6 +4139,7 @@ these steps: request.

      • Let workerStartTime be the unsafe shared current time. +

      • Set response to the result of invoking handle fetch for requestForServiceWorker. [[!HTML]] [[!SW]] @@ -4134,7 +4151,7 @@ these steps:

      • Set fetchParams's timing info's worker start time to workerStartTime. -

      • Update timing info from stored response for fetchParams's +

      • Update timing info from stored response given fetchParams's timing info and response.

      • If request's body is non-null, then @@ -4272,19 +4289,20 @@ these steps:

      • Let redirectTimingList be fetchParams's redirect timing info list. -

      • If redirectTimingList is not empty, set timingInfo's - redirect start time to redirectTimingList's first item's - fetch start time and +

      • If redirectTimingList is not empty, then set + timingInfo's redirect start time to + redirectTimingList[0]'s fetch start time and redirect end time to redirectTimingList's last item's fetch start time. -

      • Set response's timing info to timingInfo. +

      • +

        Set response's timing info to timingInfo. -

        Attaching the timing info to a response is what makes it exposed to the web as a - Resource Timing entry later. This step is done here, as resource-timing entries - are available only for HTTP fetches, including ones that are handled by service-workers or HTTP - cache, and not for data/blob/file fetches, and are only available after all the CORS checks have - passed for the request. +

        Attaching the timing info to a response is what makes it exposed to the web as a + Resource Timing entry later. This step is done here, as resource-timing entries are available only + for HTTP fetches, including ones that are handled by service-workers or HTTP cache, and not for, + e.g., data:, blob: URL fetches, and are only available after all the + relevant security checks have succeeded.

      • Return response. Typically actualResponse's body's @@ -4803,7 +4821,7 @@ steps. They return a response.

      • Set response to storedResponse. -

      • Update timing info from stored response for fetchParams's +

      • Update timing info from stored response given fetchParams's timing info and response. @@ -5025,14 +5043,15 @@ optional boolean forceNewConnection (default false), run these steps:

      • Set timingInfo's response start time to the unsafe shared current time immediately after the user agent's HTTP parser - receives the first byte of the response (e.g. frame header bytes for HTTP/2, or response - status line for HTTP/1.x), regardless of the response's status code. + receives the first byte of the response (e.g., frame header bytes for HTTP/2, or response + status line for HTTP/1.x).

      • Wait until all the headers are transmitted.

      • Any responses whose status is in the range 100 to 199, - inclusive, and is not 101, are to be ignored. + inclusive, and is not 101, are to be ignored, except for the purposes of setting + timingInfo's response start time above.

        These kind of responses are eventually followed by a "final" response. @@ -5235,7 +5254,7 @@ optional boolean forceNewConnection (default false), run these steps:

      • Otherwise, if the bytes transmission for response's message body is done normally and stream is readable, then close stream, finalize response for - response and fetchParams, and abort these in-parallel steps. + fetchParams and response, and abort these in-parallel steps. @@ -5243,7 +5262,7 @@ optional boolean forceNewConnection (default false), run these steps:

        If aborted, then:

          -
        1. Finalize response for response and fetchParams. +
        2. Finalize response for fetchParams and response.

        3. Let aborted be the termination's aborted flag. From 470e9cfb3835640a307ebb97abeaf9d6cfb4010c Mon Sep 17 00:00:00 2001 From: Anne van Kesteren Date: Tue, 23 Mar 2021 18:40:34 +0100 Subject: [PATCH 22/30] address CI issues --- fetch.bs | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/fetch.bs b/fetch.bs index 58137a2f1..738ba3daf 100644 --- a/fetch.bs +++ b/fetch.bs @@ -2227,7 +2227,7 @@ identified by a key (a network partition key), an origin (a origin), and credentials (a boolean).

          Each connection has an associated connection timing info -timingInfo. +timing info.

          To obtain a connection, given a key, origin, credentials, an optional boolean forceNew (default false), @@ -2303,7 +2303,7 @@ clearly stipulates that connections are keyed on

          To record connection timing info given a connection connection, let timingInfo be connection's -connection timing info and observe these requirements: +timing info and observe these requirements:

          -

          Suppose the user agent establishes an HTTP/2 connection over TLS 1.3 to send a - GET request and a POST request. It sends the ClientHello at time - t1 and then sends the GET request with early data. The POST - request is not safe ([[HTTP-SEMANTICS]], section 4.2.1), so the user agent waits to complete the - handshake at time t2 before sending it. Although both requests used the same - connection, the GET request reports a connection end time of t1, while the - POST request reports t2. +

          Suppose the user agent establishes an HTTP/2 + connection over TLS 1.3 to send a GET request and a POST request. It + sends the ClientHello at time t1 and then sends the GET request with early + data. The POST request is not safe ([[HTTP-SEMANTICS]], section 4.2.1), so the user + agent waits to complete the handshake at time t2 before sending it. Although both + requests used the same connection, the GET request reports a connection end time of + t1, while the POST request reports t2.

        4. If a secure transport is used, timingInfo's secure connection start time should be the result of calling @@ -2380,7 +2380,7 @@ clearly stipulates that connections are keyed on HTTP/3 protocol in the HTTP/3 Internet Draft. -

          connection's +

          timingInfo's alpn negotiated protocol is intended to identify the network protocol in use regardless of how it was actually negotiated; that is, even if ALPN is not used to negotiate the network protocol, this is the ALPN Protocol IDs that indicates the protocol in @@ -5015,7 +5015,7 @@ optional boolean forceNewConnection (default false), run these steps:

        5. Set timingInfo's connection timing info to the result of calling clamp connection timing to fetch timing with connection's - timingInfo and timingInfo's + timing info and timingInfo's fetch start time.
        6. From b11163191c6b6c62dc0f69e8296098cf248acc7a Mon Sep 17 00:00:00 2001 From: Anne van Kesteren Date: Wed, 24 Mar 2021 09:45:23 +0100 Subject: [PATCH 23/30] rename worker start and clean up ALPN Protocol ID --- fetch.bs | 41 ++++++++++++++++------------------------- 1 file changed, 16 insertions(+), 25 deletions(-) diff --git a/fetch.bs b/fetch.bs index 738ba3daf..60f3855bb 100644 --- a/fetch.bs +++ b/fetch.bs @@ -202,7 +202,7 @@ information required by the resource timing and navigation timing specs. It has
          start time (default 0)
          fetch start time (default 0) -
          worker start time (default 0) +
          service worker start time (default 0)
          request start time (default 0)
          response start time (default 0)
          response end time (default 0) @@ -230,8 +230,9 @@ information pertaining to the process of obtaining a connection. It has the foll
          secure connection start time (default 0)
          A DOMHighResTimeStamp -
          alpn negotiated protocol (default empty string) -
          A string. +
          ALPN negotiated protocol (default the empty + byte sequence) +
          A byte sequence.

          Note that timestamps in this spec are usually unsafe, and are meant to be coarsened @@ -251,8 +252,8 @@ and normalized to a global object prior to being exposed. connection start time set to defaultStartTime, connection end time set to defaultStartTime, secure connection start time set to - defaultStartTime, and alpn negotiated protocol - set to timingInfo's alpn negotiated protocol. + defaultStartTime, and ALPN negotiated protocol + set to timingInfo's ALPN negotiated protocol.

        To update timing info from stored response, given a @@ -2354,43 +2355,34 @@ clearly stipulates that connections are keyed on secure connection. [[!TLS]]

      • -

        timingInfo's alpn negotiated protocol should be +

        timingInfo's ALPN negotiated protocol should be the connection's ALPN Protocol ID, with the following caveats: [[RFC7301]] -

        • When a proxy is configured, if a tunnel connection is established then this must be the ALPN Protocol ID of the tunneled protocol, otherwise it must be the ALPN Protocol ID of the first hop to the proxy. -

        • Octets in the ALPN Protocol ID must not be percent-encoded if they are valid token - characters except "%", and when using percent-encoding, uppercase hex digits must be used. - - -

        • Formally registered ALPN Protocol IDs are documented by - IANA. - -

        • In case the user agent is using an experimental, non-registered protocol, the user agent must use the used ALPN Protocol ID, if any. If ALPN was not used for protocol negotiations, the user agent may use another descriptive string. -

          The "h3" ALPN Protocol ID is defined for the final version of the - HTTP/3 protocol in the - HTTP/3 Internet Draft. -

          timingInfo's - alpn negotiated protocol is intended to identify the network + ALPN negotiated protocol is intended to identify the network protocol in use regardless of how it was actually negotiated; that is, even if ALPN is not used to negotiate the network protocol, this is the ALPN Protocol IDs that indicates the protocol in use.

        -

        The clamp connection timing to fetch timing algorithm ensures that - details of reused connections are not exposed. +

        IANA maintains a + list of ALPN Protocol IDs. +

        The clamp connection timing to fetch timing algorithm ensures that +details of reused connections are not exposed. + +

        Network partition keys

        A network partition key is a tuple consisting of a site and null or @@ -4138,8 +4130,7 @@ these steps:

      • Let requestForServiceWorker be a clone of request. -

      • Let workerStartTime be the unsafe shared current time. - +

      • Let serviceWorkerStartTime be the unsafe shared current time.

      • Set response to the result of invoking handle fetch for requestForServiceWorker. [[!HTML]] [[!SW]] @@ -4149,7 +4140,7 @@ these steps:

        1. Set fetchParams's timing info's - worker start time to workerStartTime. + service worker start time to serviceWorkerStartTime.

        2. Update timing info from stored response given fetchParams's timing info and response. From 21e258c68617969dccfc00725bb5b6095424e443 Mon Sep 17 00:00:00 2001 From: Anne van Kesteren Date: Wed, 24 Mar 2021 11:37:25 +0100 Subject: [PATCH 24/30] coarsen times early --- fetch.bs | 117 +++++++++++++++++++++++++++++++++++++------------------ 1 file changed, 79 insertions(+), 38 deletions(-) diff --git a/fetch.bs b/fetch.bs index 60f3855bb..0507191e5 100644 --- a/fetch.bs +++ b/fetch.bs @@ -188,6 +188,9 @@ lt="authentication entry">authentication entries (for HTTP authentication).

          task destination (default null)
          Null, a global object, or a parallel queue. +
          cross-origin isolated capability (default false) +
          A boolean. +
          timing info
          A fetch timing info. @@ -208,7 +211,7 @@ information required by the resource timing and navigation timing specs. It has
          response end time (default 0)
          redirect start time (default 0)
          redirect end time (default 0) -
          A DOMHighResTimeStamp. +
          A {{DOMHighResTimeStamp}}.
          encoded body size (default 0)
          decoded body size (default 0) @@ -228,32 +231,48 @@ information pertaining to the process of obtaining a connection. It has the foll
          connection start time (default 0)
          connection end time (default 0)
          secure connection start time (default 0) -
          A DOMHighResTimeStamp +
          A {{DOMHighResTimeStamp}}.
          ALPN negotiated protocol (default the empty byte sequence)
          A byte sequence. -

          Note that timestamps in this spec are usually unsafe, and are meant to be coarsened -and normalized to a global object prior to being exposed. - -

          To clamp connection timing to fetch timing, given a -connection timing info timingInfo and a -DOMHighResTimeStamp defaultStartTime, run these steps: +

          To clamp and coarsen connection timing info, given a +connection timing info timingInfo, a {{DOMHighResTimeStamp}} +defaultStartTime, and a boolean crossOriginIsolatedCapability, run these +steps:

          1. If timingInfo's connection start time is - greater than defaultStartTime, then return timingInfo. - -

          2. Return a new connection timing info, with - domain lookup start time set to defaultStartTime, - domain lookup end time set to defaultStartTime, - connection start time set to defaultStartTime, - connection end time set to defaultStartTime, - secure connection start time set to - defaultStartTime, and ALPN negotiated protocol - set to timingInfo's ALPN negotiated protocol. + less than defaultStartTime, then return a new connection timing info whose + domain lookup start time is defaultStartTime, + domain lookup end time is defaultStartTime, + connection start time is defaultStartTime, + connection end time is defaultStartTime, + secure connection start time is defaultStartTime, + and ALPN negotiated protocol is timingInfo's + ALPN negotiated protocol. + +

          3. Return a new connection timing info whose + domain lookup start time is the result of coarsen time + given timingInfo's domain lookup start time and + crossOriginIsolatedCapability, + domain lookup end time is the result of coarsen time + given timingInfo's domain lookup end time and + crossOriginIsolatedCapability, connection start time + is the result of coarsen time given timingInfo's + connection start time and + crossOriginIsolatedCapability, connection end time + is the result of coarsen time given timingInfo's + connection end time and + crossOriginIsolatedCapability, + secure connection start time is the result of + coarsen time given timingInfo's + connection end time and + crossOriginIsolatedCapability, and + ALPN negotiated protocol is timingInfo's + ALPN negotiated protocol.

          To update timing info from stored response, given a @@ -2230,6 +2249,8 @@ identified by a key (a network partition key), an origin (a

          Each connection has an associated connection timing info timing info. +

          +

          To obtain a connection, given a key, origin, credentials, an optional boolean forceNew (default false), an optional boolean http3Only (default @@ -2379,8 +2400,8 @@ clearly stipulates that connections are keyed on list of ALPN Protocol IDs.

        -

        The clamp connection timing to fetch timing algorithm ensures that -details of reused connections are not exposed. +

        The clamp and coarsen connection timing info algorithm ensures that +details of reused connections are not exposed and time values are coarsened.

        Network partition keys

        @@ -3513,13 +3534,23 @@ the request.

        1. Let taskDestination be null. +

        2. Let crossOriginIsolatedCapability be false. + +

        3. +

          If request's client is non-null, then: + +

            +

          1. Set taskDestination to request's client's + global object. + +

          2. Set crossOriginIsolatedCapability to request's + client's + cross-origin isolated capability. +

          +

        4. If useParallelQueue is true, then set taskDestination to the result of starting a new parallel queue. -

        5. Otherwise, if request's client is non-null, set - taskDestination to request's client's - global object. - +

          +

          To record connection timing info given a connection connection, let timingInfo be connection's timing info and observe these requirements: From b37ef51dc3e57ce2624fe15f4fbd312ffed46c94 Mon Sep 17 00:00:00 2001 From: Noam Rosenthal Date: Wed, 24 Mar 2021 13:24:43 +0200 Subject: [PATCH 26/30] Simplify redirects --- fetch.bs | 23 +++++++++-------------- 1 file changed, 9 insertions(+), 14 deletions(-) diff --git a/fetch.bs b/fetch.bs index f44e6467d..2057abf7a 100644 --- a/fetch.bs +++ b/fetch.bs @@ -193,9 +193,6 @@ lt="authentication entry">authentication entries (for HTTP authentication).

          timing info
          A fetch timing info. - -
          redirect timing info list (default « ») -
          A list of 0 or more fetch timing info.

          A fetch timing info is a struct used to maintain timing @@ -4317,15 +4314,6 @@ these steps:

        -

      • Let redirectTimingList be fetchParams's - redirect timing info list. - -

      • If redirectTimingList is not empty, then set - timingInfo's redirect start time to - redirectTimingList[0]'s fetch start time and - redirect end time to redirectTimingList's last item's - fetch start time. -

      • Set response's timing info to timingInfo. @@ -4420,8 +4408,15 @@ run these steps:

        request's body's source's nullity has already been checked. -

      • Append fetchParams's timing info to - fetchParams's redirect timing info list. +

      • Let timingInfo be fetchParams's timing info. + +

      • Set timingInfo's redirect end time to the + coarsened shared current time given fetchParams's + cross-origin isolated capability. + +

      • If timingInfo's redirect start time is 0, then set + timingInfo's redirect start time to + timingInfo's fetch start time.

      • Append locationURL to request's URL list. From ce317dcd48528df7dd706b3bafc4b4dab177d170 Mon Sep 17 00:00:00 2001 From: Noam Rosenthal Date: Wed, 24 Mar 2021 13:32:15 +0200 Subject: [PATCH 27/30] Update fetch.bs Co-authored-by: Anne van Kesteren --- fetch.bs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fetch.bs b/fetch.bs index 2057abf7a..66c0bb40d 100644 --- a/fetch.bs +++ b/fetch.bs @@ -2397,7 +2397,7 @@ clearly stipulates that connections are keyed on

        IANA maintains a list of ALPN Protocol IDs. - +

      The clamp and coarsen connection timing info algorithm ensures that details of reused connections are not exposed and time values are coarsened. From 2b6e0cce294c269029e8fef4668fe987f18f3910 Mon Sep 17 00:00:00 2001 From: Noam Rosenthal Date: Wed, 24 Mar 2021 17:04:54 +0200 Subject: [PATCH 28/30] trigger GitHub actions From 52fd63b2ce2f941db140c75a2f7c3939b7782895 Mon Sep 17 00:00:00 2001 From: Anne van Kesteren Date: Thu, 25 Mar 2021 11:31:25 +0100 Subject: [PATCH 29/30] Address remaining issues --- fetch.bs | 71 +++++++++++++++++++++++++------------------------------- 1 file changed, 32 insertions(+), 39 deletions(-) diff --git a/fetch.bs b/fetch.bs index 66c0bb40d..a7616a1a1 100644 --- a/fetch.bs +++ b/fetch.bs @@ -201,20 +201,20 @@ information required by the resource timing and navigation timing specs. It has

      start time (default 0) -
      fetch start time (default 0) -
      service worker start time (default 0) -
      request start time (default 0) -
      response start time (default 0) -
      response end time (default 0)
      redirect start time (default 0)
      redirect end time (default 0) +
      post-redirect start time (default 0) +
      final service worker start time (default 0) +
      final network-request start time (default 0) +
      final network-response start time (default 0) +
      end time (default 0)
      A {{DOMHighResTimeStamp}}.
      encoded body size (default 0)
      decoded body size (default 0)
      A number. -
      connection timing info (default null) +
      final connection timing info (default null)
      Null or a connection timing info.
      @@ -2189,8 +2189,9 @@ unset or keepalive is false, termi identified by a key (a network partition key), an origin (an origin), and credentials (a boolean). -

      Each connection has an associated connection timing info -timing info. +

      Each connection has an associated +timing info (a +connection timing info).

      A connection timing info is a struct used to maintain timing information pertaining to the process of obtaining a connection. It has the following @@ -3555,9 +3556,14 @@ the request. wanting to do a ping without request body might do so as well, but if you do have a request body you definitely need this as otherwise transmit-request-body loop breaks down. --> +

    • Let timingInfo be a new fetch timing info whose + start time and + post-redirect start time are the + coarsened shared current time given crossOriginIsolatedCapability. +

    • Let fetchParams be a new fetch params whose request is request, - timing info is a new fetch timing info, + timing info is timingInfo, process request body is processRequestBody, process request end-of-body is processRequestEndOfBody, process response is processResponse, @@ -3649,10 +3655,6 @@ steps:

    • Let response be null. -

    • Set fetchParams's timing info's - fetch start time to the coarsened shared current time - given fetchParams's cross-origin isolated capability. -

    • If request's local-URLs-only flag is set and request's current URL is not local, then set response to a network error. @@ -3981,12 +3983,6 @@ steps: response response, run these steps:

        -

      1. Let timingInfo be response's timing info. - -

      2. If timingInfo is not null, then set timingInfo's - response end time to the coarsened shared current time - given fetchParams's cross-origin isolated capability. -

      3. Set fetchParams's request's done flag. @@ -4010,19 +4006,13 @@ steps:

      4. If timingInfo is null, then return. -

      5. Let startTime be timingInfo's - fetch start time. - -

      6. If timingInfo's redirect start time is not 0, then - set startTime to timingInfo's - redirect start time. -

      7. If response's timing allow passed flag is not set, then set - timingInfo to a new fetch timing info, with its - start time and fetch start time set - to startTime. + timingInfo to a new fetch timing info whose + start time and + post-redirect start time are timingInfo's + start time. -

      8. Set timingInfo's response end time to the +

      9. Set timingInfo's end time to the coarsened shared current time given global's relevant settings object's cross-origin isolated capability. @@ -4177,7 +4167,8 @@ these steps:

        1. Set fetchParams's timing info's - service worker start time to serviceWorkerStartTime. + final service worker start time to + serviceWorkerStartTime.

        2. Update timing info from stored response given fetchParams's timing info and response. @@ -4410,13 +4401,14 @@ run these steps:

        3. Let timingInfo be fetchParams's timing info. -

        4. Set timingInfo's redirect end time to the +

        5. Set timingInfo's redirect end time and + post-redirect start time to the coarsened shared current time given fetchParams's cross-origin isolated capability.

        6. If timingInfo's redirect start time is 0, then set timingInfo's redirect start time to - timingInfo's fetch start time. + timingInfo's start time.

        7. Append locationURL to request's URL list. @@ -5039,10 +5031,10 @@ optional boolean forceNewConnection (default false), run these steps: includeCredentials, and forceNewConnection. -

        8. Set timingInfo's connection timing info to the +
        9. Set timingInfo's final connection timing info to the result of calling clamp and coarsen connection timing info with connection's timing info, timingInfo's - fetch start time, and fetchParams's + post-redirect start time, and fetchParams's cross-origin isolated capability.
        10. @@ -5058,8 +5050,8 @@ optional boolean forceNewConnection (default false), run these steps: `Transfer-Encoding`/`chunked` to request's header list. -
        11. Set timingInfo's request start time to the - coarsened shared current time given fetchParams's +
        12. Set timingInfo's final network-request start time + to the coarsened shared current time given fetchParams's cross-origin isolated capability.
        13. @@ -5069,7 +5061,8 @@ optional boolean forceNewConnection (default false), run these steps:

          • Follow the relevant requirements from HTTP. [[!HTTP]] [[!HTTP-SEMANTICS]] [[!HTTP-COND]] [[!HTTP-CACHING]] [[!HTTP-AUTH]] -

          • Set timingInfo's response start time to the +

          • 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 HTTP/2 or @@ -5080,7 +5073,7 @@ optional boolean forceNewConnection (default false), run these steps:

          • Any responses whose status is in the range 100 to 199, inclusive, and is not 101, are to be ignored, except for the purposes of setting - timingInfo's response start time above. + timingInfo's final network-response start time above.

            These kind of responses are eventually followed by a "final" response. From 66772da510b04cad85c0f4d4005184c50da19d3d Mon Sep 17 00:00:00 2001 From: Anne van Kesteren Date: Thu, 25 Mar 2021 11:41:08 +0100 Subject: [PATCH 30/30] nits --- fetch.bs | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/fetch.bs b/fetch.bs index a7616a1a1..991f6b6c2 100644 --- a/fetch.bs +++ b/fetch.bs @@ -196,8 +196,8 @@ lt="authentication entry">authentication entries (for HTTP authentication).

            A fetch timing info is a struct used to maintain timing -information required by the resource timing and navigation timing specs. It has the following -items: +information needed by Resource Timing and Navigation Timing. It has the +following items: [[RESOURCE-TIMING]] [[NAVIGATION-TIMING]]

            start time (default 0) @@ -2198,16 +2198,16 @@ information pertaining to the process of obtaining a connection. It has the foll items:
            -
            domain lookup start time (default 0) -
            domain lookup end time (default 0) -
            connection start time (default 0) -
            connection end time (default 0) -
            secure connection start time (default 0) -
            A {{DOMHighResTimeStamp}}. - -
            ALPN negotiated protocol (default the empty - byte sequence) -
            A byte sequence. +
            domain lookup start time (default 0) +
            domain lookup end time (default 0) +
            connection start time (default 0) +
            connection end time (default 0) +
            secure connection start time (default 0) +
            A {{DOMHighResTimeStamp}}. + +
            ALPN negotiated protocol (default the empty + byte sequence) +
            A byte sequence.

            To clamp and coarsen connection timing info, given a