-
Notifications
You must be signed in to change notification settings - Fork 332
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
Pass in content type to resource-timing #1481
Conversation
9c9e580
to
b4299c2
Compare
b4299c2
to
b9f7ba9
Compare
It also seems like we need to have w3c/server-timing#89 resolved before continuing here. |
@annevk the equivalent concerns related to this are currently handled in the ResourceTiming PR, essentially enabling user agents to trim entropy off of mime types to align them with a well-known list. We tried to go off a well-known list of types in MIMESNIFF, but there seem to be types that have inherent entropy in their essence ("+zip" and "+xml" types specifically) which made that unreasonably hard. So, I guess the open questions are: /cc @achristensen07 |
I think it should happen in Fetch, if that is something that we plan on doing. I also think it should be standardized as it seems like it could be an interop hazard. Could we perhaps normalize +zip to application/zip and +xml to application/xml and call it a day? And perhaps special case a few types such as image/svg+xml so they are preserved. |
I'm wary of pushing for a complex mechanism here, given that there's no consensus that w3c/server-timing#89 is indeed an issue. Does the fact that this would require CORS (rather than TAO) change the calculus on Apple's threat model? |
@yoavweiss I think so, but then we also don't need stripping to just the essence, right? Not entirely clear to me how that relates to the "navigate"-related aspects of this PR, either. |
From my perspective, we don't need that (for neither this nor ServerTiming, which is TAO protected). I know that @achristensen07 disagrees with me on the ServerTiming/TAO aspects, but I'm not sure if he does on exposing such info to CORS enabled resources.
For the "navigate" parts, they require same-origin, so I don't think @achristensen07's threat model applies there. |
This CL introduces a contentType field to Performance Resource Timing object. This field is behind a Runtime Enabled Flag. Resource Timing PR : w3c/resource-timing#341 Fetch PR : whatwg/fetch#1481 Bug:1366706 Change-Id: If4c92ef96d74e3ddbb71420ac61dbea4bfa1163b
This CL introduces a contentType field to Performance Resource Timing object. This field is behind a Runtime Enabled Flag. Resource Timing PR : w3c/resource-timing#341 Fetch PR : whatwg/fetch#1481 Bug: 1366706 Change-Id: If4c92ef96d74e3ddbb71420ac61dbea4bfa1163b Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3916841 Reviewed-by: Yoav Weiss <[email protected]> Reviewed-by: Mike West <[email protected]> Commit-Queue: Abin Paul <[email protected]> Cr-Commit-Position: refs/heads/main@{#1063289}
This CL introduces a contentType field to Performance Resource Timing object. This field is behind a Runtime Enabled Flag. Resource Timing PR : w3c/resource-timing#341 Fetch PR : whatwg/fetch#1481 Bug: 1366706 Change-Id: If4c92ef96d74e3ddbb71420ac61dbea4bfa1163b Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3916841 Reviewed-by: Yoav Weiss <[email protected]> Reviewed-by: Mike West <[email protected]> Commit-Queue: Abin Paul <[email protected]> Cr-Commit-Position: refs/heads/main@{#1063289}
This CL introduces a contentType field to Performance Resource Timing object. This field is behind a Runtime Enabled Flag. Resource Timing PR : w3c/resource-timing#341 Fetch PR : whatwg/fetch#1481 Bug: 1366706 Change-Id: If4c92ef96d74e3ddbb71420ac61dbea4bfa1163b Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3916841 Reviewed-by: Yoav Weiss <[email protected]> Reviewed-by: Mike West <[email protected]> Commit-Queue: Abin Paul <[email protected]> Cr-Commit-Position: refs/heads/main@{#1063289}
9cb87bf
to
9dab8eb
Compare
@annevk - friendly ping! Do we need the essence stripping from your perspective? |
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.
Right, I agree we can expose this as-is. Content-Type
is a safelisted response header when it comes to CORS.
…iming, a=testonly Automatic update from web-platform-tests Add content-type to PerformanceResourceTiming This CL introduces a contentType field to Performance Resource Timing object. This field is behind a Runtime Enabled Flag. Resource Timing PR : w3c/resource-timing#341 Fetch PR : whatwg/fetch#1481 Bug: 1366706 Change-Id: If4c92ef96d74e3ddbb71420ac61dbea4bfa1163b Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3916841 Reviewed-by: Yoav Weiss <[email protected]> Reviewed-by: Mike West <[email protected]> Commit-Queue: Abin Paul <[email protected]> Cr-Commit-Position: refs/heads/main@{#1063289} -- wpt-commits: 4c8e480994182b5cdc60f5c01ebf208df70ec73e wpt-pr: 36059
9dab8eb
to
4086857
Compare
c231b11
to
948dc1b
Compare
@abinpaul1 looking at the Chromium patch it strikes me that it might not do MIME type parsing currently. I think it would be good if we had test coverage for that. https://github.com/web-platform-tests/wpt/tree/master/fetch/content-type has some existing tests you might be able to reuse. I'm also gonna push a small fixup commit for an existing formatting issue in the |
…iming, a=testonly Automatic update from web-platform-tests Add content-type to PerformanceResourceTiming This CL introduces a contentType field to Performance Resource Timing object. This field is behind a Runtime Enabled Flag. Resource Timing PR : w3c/resource-timing#341 Fetch PR : whatwg/fetch#1481 Bug: 1366706 Change-Id: If4c92ef96d74e3ddbb71420ac61dbea4bfa1163b Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3916841 Reviewed-by: Yoav Weiss <[email protected]> Reviewed-by: Mike West <[email protected]> Commit-Queue: Abin Paul <[email protected]> Cr-Commit-Position: refs/heads/main@{#1063289} -- wpt-commits: 4c8e480994182b5cdc60f5c01ebf208df70ec73e wpt-pr: 36059
@annevk Added tests for checking the parsing over at https://chromium-review.googlesource.com/c/chromium/src/+/4058549. |
@abinpaul1 I didn't realize that directory doesn't test a bunch of the error cases around MIME type handling. It's essentially only handling the However, it also seems like you're expecting the wrong thing. It should be the mimeType field, not documentContentType, right? |
I've tried to include those as well now. Please have another look
Yeah. Changed to |
Thanks, that looks good. For the problem you're running into with |
Thanks again for the pointers. Updated the tests now (extra checks similar to charset-parameter.window.js#L41 before running the test case from json. |
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.
This looks good. At this point we need either Gecko or WebKit to support this change.
Seems like Gecko are now supportive. |
Is there anything still blocking this PR from landing? |
Apologies for the delay here. I was out the last couple weeks and only just circled back with Alex about his objection to this feature. I laid out a path forward in WebKit/standards-positions#88 (comment) that I'm prepared to help with. Feedback from you all as well as @zcorpan @bdekoz @sefeng211 appreciated. |
See WebKit/standards-positions#88 (comment) for rationale. whatwg/fetch#1481 will be updated to call this.
I put up whatwg/mimesniff#171 which we could call here so the least amount of information leaves the network layer. Seems cleanest. That would require a slight restructuring, but nothing too bad and it would make the Resource Timing side very straightforward. @yoavweiss indicated support in WebKit/standards-positions#88 (comment). Once I've had review of the MIME Sniffing PR I would be happy to update this PR as well and provide instructions for the Resource Timing PR. |
See WebKit/standards-positions#88 (comment) for rationale. whatwg/fetch#1481 will be updated to call this.
This defines the content type field as a minimized version of the response's parsed Content-Type header, to give web developers enough information to distinguish responses, but not enough to make it an additional communication channel. This feature will be used by Resource Timing as per w3c/resource-timing#341. Tests: ...
@abinpaul1 I updated this to account for the MIME Sniffing change (doesn't pass CI yet due to indexing, probably tomorrow). Will you update the tests? |
@annevk Yeah..I can do that. Couple of things I wanted to clarify before updating the same.
|
@abinpaul1 I think we could add a For types that fall into the "is supported by" conditional, I suggest we stick with types we know all browsers implement. And keep types that are in the process of being standardized/implemented in a tentative file or some such. Also, did we have cross-origin tests already? If not we probably should have some as well, even if only for images and scripts or some such. |
I've updated the tests here : https://chromium-review.googlesource.com/c/chromium/src/+/4509283
I'm not sure if I know which types are being standardized and have to be included as tentative. Would it make sense for us to just add them to the JSON for the minimized algorithm tests later when they do become standardized ?
I think these were covered in content-type.html - 1 and 2 |
That seems fine, but e.g., you could assume " |
These changes are to support addition of content type attribute to Perfomance resource timing. Further details are available at w3c/resource-timing#341
(See WHATWG Working Mode: Changes for more details.)
Preview | Diff