Re: [whatwg/fetch] Initial resource timing integration. (#1185)

@yoavweiss commented on this pull request.

One last comment beyond editorials

> @@ -3898,20 +4116,31 @@ these steps:
 
  <li><p>Let <var>actualResponse</var> be null.
 
+ <li><p>Let <var>timingInfo</var> be <var>fetchParams</var>'s<a for="fetch params">timing

Editorial nit: missing space between fetchParams and the next word.
Also, no need for "'s" after fetchParams here and elsewhere, as "'" would be sufficient

>     <li>
     <p>Set <var>response</var> to the result of making an HTTP request over <var>connection</var>
     using <var>request</var> with the following caveats:
 
     <ul>
      <li><p>Follow the relevant requirements from HTTP. [[!HTTP]] [[!HTTP-SEMANTICS]] [[!HTTP-COND]] [[!HTTP-CACHING]] [[!HTTP-AUTH]]
 
+     <li><p>Set <var>timingInfo</var>'s <a for="fetch timing info">response start time</a> to
+     the <a for=/>unsafe shared current time</a>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).
+
      <li><p>Wait until all the <a for=/>headers</a> are transmitted.
 
      <li>

Digging further, we explicitly have a test that contradicts this: https://github.com/web-platform-tests/wpt/blob/master/resource-timing/resource-timing-level1.js#L238

Chromium and Mozilla agree on this: https://wpt.fyi/results/resource-timing/resource-timing-level1.sub.html?label=experimental&label=master&aligned (with Safari failing)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/pull/1185#pullrequestreview-618359170