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
Add delivery type to PerformanceResourceTiming. #343
Add delivery type to PerformanceResourceTiming. #343
Conversation
1184d93
to
77917b8
Compare
This is missing WPT tests at present. I understand if merging this is blocked on that, but would you mind having a look @noamr ? I expect the tests for this will be relatively straightforward (at least, once we have an implementation in Chromium to avoid test bugs). |
77917b8
to
343238a
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, but I'd love to run this by the WG and see if there are any objections, as well as get tests in place before this lands.
This defines a concept of "delivery type" which currently describes the difference between resources delivered from the HTTP cache and those not (currently only detectable via transferSize). It is expected to be extended to describe resources delivered from other stores, such as the consuming resources from the HTML preload buffer and navigational prefetches.
343238a
to
73cdda2
Compare
Is TPAC a good venue for that? If so are there steps I should take to get it on the agenda? |
We can probably cover this on today's call. |
Question: Would this attribute be gated by same-origin or TAO/CORS? For the Other than that, the other states that this could have for e.g. nav prefetch seem useful. |
Summary from 9/1 W3C WebPerf call:
|
Thinking out loud regarding the need for restrictions here: While not significant on its own, this could be sufficient to reveal user state in cases where the cachability of the resource varies between e.g. logged-in and non-logged-in users. So, I think we want this to be TAO protected. /cc @arturjanc and @mikewest to tell me if I'm being overly paranoid about this or overly optimistic about this not already being leaked through timing. |
I think that tracks. I think the strongest counterarguments would be:
I'm not opposed to TAO protection, though, and presumably anyone gathering RUM is also serving their important cross-origin resources with a suitable TAO header. If that is the resolution, the behavior I propose is that the if |
On further investigation, I think the current text in this PR already implies a TAO check in the following way: Fetch says:
This is then used to populate the cache mode and thus the default delivery type, so "setup the resource timing entry" won't see the |
bcbc75b
to
a1130b5
Compare
Status update:
I believe that covers the identified items. @yoavweiss what is the next step under the group's working mode? |
#369 seems to be general verbiage that I think covers any application it would have to this PR. I'd like to renew my request to know what the next step/milestone here is. |
This is LGTM, @yoavweiss do you want to take another look? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Addresses #332.
This defines a concept of "delivery type" which currently describes the difference between resources delivered from the HTTP cache and those not (currently only detectable via transferSize). It is expected to be extended to describe resources delivered from other stores, such as the consuming resources from the HTML preload buffer and navigational prefetches.
Preview | Diff