Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Initial resource timing integration. #1185

Merged
merged 30 commits into from
Mar 25, 2021

Conversation

noamr
Copy link
Contributor

@noamr noamr commented Mar 2, 2021

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 w3c/resource-timing#252


Preview | Diff

@noamr
Copy link
Contributor Author

noamr commented Mar 2, 2021

@annevk @yoavweiss

fetch.bs Outdated Show resolved Hide resolved
fetch.bs Outdated Show resolved Hide resolved
fetch.bs Show resolved Hide resolved
fetch.bs Outdated Show resolved Hide resolved
noamr added a commit to w3c/hr-time that referenced this pull request Mar 3, 2021
"global" is a term already used to describe the global
object, while this monotonic clock is shared across globals
(e.g. workers and the window).

Also expose "current universal time", for use by Fetch.
See whatwg/fetch#1185
fetch.bs Outdated Show resolved Hide resolved
fetch.bs Outdated Show resolved Hide resolved
fetch.bs Outdated Show resolved Hide resolved
fetch.bs Outdated Show resolved Hide resolved
fetch.bs Outdated Show resolved Hide resolved
fetch.bs Outdated Show resolved Hide resolved
fetch.bs Outdated Show resolved Hide resolved
fetch.bs Outdated Show resolved Hide resolved
fetch.bs Outdated Show resolved Hide resolved
fetch.bs Outdated Show resolved Hide resolved
Copy link
Member

@annevk annevk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would help a lot if you checked the final diff and read through it at least once to make sure there are no obvious mistakes there. At least I personally tend to spot a lot of mistakes when doing that in my own writing.

Overall I think this approach looks good. I'm a little worried about it also relying on the "done flag" badness. Perhaps the solution there is to accept that implementations are not full duplex and so once the response stream is closed it's really all over.

One thing I haven't done in detail is ensuring that the point of capture matches RT and matches implementations. For that it would be helpful to have some pointers to tests. As I also noted I would prefer to not define fields we're unsure of or that can be inferred from other fields.

(I also do not see transfer size, was that omitted intentionally?)

fetch.bs Outdated Show resolved Hide resolved
fetch.bs Outdated Show resolved Hide resolved
fetch.bs Outdated Show resolved Hide resolved
fetch.bs Outdated Show resolved Hide resolved
fetch.bs Outdated Show resolved Hide resolved
fetch.bs Outdated Show resolved Hide resolved
fetch.bs Outdated Show resolved Hide resolved
fetch.bs Outdated Show resolved Hide resolved
fetch.bs Outdated Show resolved Hide resolved
fetch.bs Outdated Show resolved Hide resolved
@noamr
Copy link
Contributor Author

noamr commented Mar 7, 2021

It would help a lot if you checked the final diff and read through it at least once to make sure there are no obvious mistakes there. At least I personally tend to spot a lot of mistakes when doing that in my own writing.

Sorry for that. I will double check next time.

Overall I think this approach looks good. I'm a little worried about it also relying on the "done flag" badness. Perhaps the solution there is to accept that implementations are not full duplex and so once the response stream is closed it's really all over.

One thing I haven't done in detail is ensuring that the point of capture matches RT and matches implementations. For that it would be helpful to have some pointers to tests. As I also noted I would prefer to not define fields we're unsure of or that can be inferred from other fields.

(I also do not see transfer size, was that omitted intentionally?)

Yes. transfer size will become encoded body size + some constant number, and that will be done in RT.

@noamr noamr force-pushed the fetch-resource-timing-initial branch 3 times, most recently from 7496b4a to d0e2408 Compare March 7, 2021 15:24
@noamr
Copy link
Contributor Author

noamr commented Mar 8, 2021

See issue for adding connection tests: web-platform-tests/wpt#27935

@noamr noamr force-pushed the fetch-resource-timing-initial branch 3 times, most recently from e1a3e17 to 526a3d1 Compare March 8, 2021 17:07
fetch.bs Outdated Show resolved Hide resolved
Copy link
Member

@annevk annevk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's still a lot of style issues left that I mostly tried to read over. I left some questions for things that are unclear. I checked some of the timings, but that could use another look as well. Is @yoavweiss also looking at those?

fetch.bs Outdated Show resolved Hide resolved
fetch.bs Outdated Show resolved Hide resolved
fetch.bs Outdated Show resolved Hide resolved
fetch.bs Outdated Show resolved Hide resolved
fetch.bs Outdated Show resolved Hide resolved
fetch.bs Outdated Show resolved Hide resolved
fetch.bs Outdated Show resolved Hide resolved
fetch.bs Outdated Show resolved Hide resolved
fetch.bs Outdated Show resolved Hide resolved
fetch.bs Outdated Show resolved Hide resolved
fetch.bs Outdated Show resolved Hide resolved
fetch.bs Outdated Show resolved Hide resolved
fetch.bs Outdated Show resolved Hide resolved
fetch.bs Outdated Show resolved Hide resolved
fetch.bs Outdated Show resolved Hide resolved
fetch.bs Outdated Show resolved Hide resolved
@noamr noamr force-pushed the fetch-resource-timing-initial branch 3 times, most recently from 0538a2f to 10cb532 Compare March 9, 2021 16:11
@annevk
Copy link
Member

annevk commented Mar 10, 2021

I would like to see a test for a synthetic response from a service worker. Per the current set of definitions most fields would end up being 0, but is that what implementations do?

Similarly, testing data: URLs and blob: URLs might also highlight some problems.

@noamr noamr force-pushed the fetch-resource-timing-initial branch 5 times, most recently from b19b46e to a96f625 Compare March 11, 2021 11:48
fetch.bs Outdated Show resolved Hide resolved
@noamr noamr force-pushed the fetch-resource-timing-initial branch from 903f911 to b37ef51 Compare March 24, 2021 11:25
noamr and others added 2 commits March 24, 2021 13:32
Co-authored-by: Anne van Kesteren <annevk@annevk.nl>
fetch.bs Outdated

<li><p>If <var>timingInfo</var>'s <a for="fetch timing info">redirect start time</a> is not 0, then
set <var>startTime</var> to <var>timingInfo</var>'s
<a for="fetch timing info">redirect start time</a>.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry I missed this.

Why would we do this for the case where we cannot reveal information?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure what you're asking. The redirect start time is not revealing, as it occurs before the first redirect and keeps all the redirect info obscure.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But doesn't that reveal there was a redirect?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No. It sets startTime to be the redirect start time, so it exposes a startTime, and the caller doesn't know that its from a redirect

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I do performance.now() and then invoke fetch() it seems I would be able to tell quite easily it's not the actual start time and instead something from the network.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

w3c/resource-timing#260 :)
This PR actually fixes that, as startTime would mean redirectStart, the time before the first redirect, and not fetchStart, the time after the last redirect.

@noamr
Copy link
Contributor Author

noamr commented Mar 24, 2021

Commit message:

Take note of the different timings required for the resource timing spec.

The particular points where time is measured is based on the current Resource Timing spec, and the missing parts reflect current implementations:

  • fetchStart, requestStart, responseStart, redirectStart, redirectEnd, workerStart, encodedBodySize and decodedBodySize are handled as part of the FETCH processing model
  • the rest of the metrics are handled as requirements given to the HTTP connection obtaining processing model, which is not in itself part of the FETCH spec.

Note that FETCH doesn't decide when to enqueue the resource timing entry, but rather creates the data structure that holds the different timings, and it's up to the caller to enqueue. FETCH sends a new event, processResponseDone, when the response is closed or EOFs, which lets callers like the fetch() API enqueue the entry at the right time.
This change also makes that call as part of fetch().

It's the first phase for addressing w3c/resource-timing#252, which contains a link to the other required multi-repo steps to address RT/NT/HTML/Fetch integration.

@annevk
Copy link
Member

annevk commented Mar 25, 2021

That description misses: startTime and responseEnd.

@annevk
Copy link
Member

annevk commented Mar 25, 2021

Outstanding issues:

  • start time isn't set
  • if TAO isn't there we should reset to start time, not fetch start time
  • I think we should rename fields to more accurately capture their semantics:
    • fetch start time -> final fetch start time (even that isn't super clear, but I'm hesitant to use final main fetch start time; one thing that is weird with final fetch start time is that with a 401 scenario it wouldn't capture the time the subsequent authenticated fetch started, as that doesn't go through main fetch)
    • request start time -> network request start time (it's 0 if there's a service worker involved)
    • response start time -> network response start time (it's 0 if there's a service worker involved)
    • response end time -> end time (aligns with start time and is clearer if there's a service worker involved as it'll be non-0)

@noamr
Copy link
Contributor Author

noamr commented Mar 25, 2021

Outstanding issues:

  • start time isn't set
  • if TAO isn't there we should reset to start time, not fetch start time

Not sure what you mean. when TAO isn't there we reset both fetch start time and start time, to avoid exposing the fact that there were redirects.

  • I think we should rename fields to more accurately capture their semantics:

    • fetch start time -> final fetch start time (even that isn't super clear, but I'm hesitant to use final main fetch start time; one thing that is weird with final fetch start time is that with a 401 scenario it wouldn't capture the time the subsequent authenticated fetch started, as that doesn't go through main fetch)

Right, it would capture that start of that fetch, as 401 is not exactly a redirect. It's more like a "post-redirect fetch start time".

  • request start time -> network request start time (it's 0 if there's a service worker involved)
  • response start time -> network response start time (it's 0 if there's a service worker involved)
  • response end time -> end time (aligns with start time and is clearer if there's a service worker involved as it'll be non-0)

OK. I don't mind the renames

@annevk
Copy link
Member

annevk commented Mar 25, 2021

In https://whatpr.org/fetch/1185.html#finalize-and-report-timing step 5 we initialize startTime to fetch start time. At that point fetch start time is not guaranteed to be equal to start time, right? Then step 6 compensates for that. Then step 7 does the reset. But why not initialize startTime to start time and drop step 6? It seems that would be a lot clearer.

I really like post-redirect fetch start time by the way, let's use that! Or maybe even post-redirect start time. No need to mention fetch.

Copy link
Collaborator

@yoavweiss yoavweiss left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Still LGTM

I like the new names, even if they diverge from the web exposed ones, as they are indeed more descriptive.

@annevk annevk merged commit 73f01f7 into whatwg:main Mar 25, 2021
noamr added a commit to noamr/html that referenced this pull request Mar 25, 2021
Create a "document load timing info" struct, associated with
a document, which receives its information from several sources:
- fetch timing of the navigation response
- Load/DOMContentLoaded event dispatches
- Document readyness state changes
- sending unload events to the previous document, if it comes from the
  same origin.

See w3c/navigation-timing#136
Depends on whatwg/fetch#1185
noamr added a commit to noamr/html that referenced this pull request Apr 7, 2021
Create a "document load timing info" struct, associated with
a document, which receives its information from several sources:
- fetch timing of the navigation response
- Load/DOMContentLoaded event dispatches
- Document readyness state changes
- sending unload events to the previous document, if it comes from the
  same origin.

See w3c/navigation-timing#136
Depends on whatwg/fetch#1185
noamr added a commit to noamr/xhr that referenced this pull request Dec 14, 2021
When response is a network error or body is fully read,
finalize and report the response.

Depends on whatwg/fetch#1185

See:
w3c/resource-timing#261
and w3c/resource-timing#252
annevk pushed a commit to whatwg/xhr that referenced this pull request Feb 11, 2022
When response is a network error or body is fully read, finalize and report the response.

Depends on whatwg/fetch#1185.

Also see w3c/resource-timing#261 and w3c/resource-timing#252.
Bishwarupjee pushed a commit to Bishwarupjee/xhr that referenced this pull request Jan 31, 2024
When response is a network error or body is fully read, finalize and report the response.

Depends on whatwg/fetch#1185.

Also see w3c/resource-timing#261 and w3c/resource-timing#252.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants