Skip to content

expose contentEncoding in resourceTiming #467

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

Open
guohuideng2024 opened this issue Mar 4, 2025 · 2 comments
Open

expose contentEncoding in resourceTiming #467

guohuideng2024 opened this issue Mar 4, 2025 · 2 comments

Comments

@guohuideng2024
Copy link

guohuideng2024 commented Mar 4, 2025

WebKittens

@annevk

Title of the proposal

expose contentEncoding in resourceTiming

URL to the spec

whatwg/fetch#1796

URL to the spec's repository

https://github.com/whatwg/fetch

Issue Tracker URL

No response

Explainer URL

https://github.com/guohuideng2024/resource-timing/blob/gh-pages/Explainers/Content_Encoding.md

TAG Design Review URL

No response

Mozilla standards-positions issue URL

mozilla/standards-positions#1189

WebKit Bugzilla URL

No response

Radar URL

No response

Description

Propose that we add an explicit .contentEncoding in resourceTiming.

contentEncoding value has been very helpful for web apps and CDN in monitoring and optimization. As more compressions are deployed, it's no longer practical to infer such value. Therefore, it's desirable to explicitly expose it.

@annevk
Copy link
Contributor

annevk commented Mar 5, 2025

By-and-large this seems reasonable, but it really needs to have the same kind of minimization of information that we have in place for exposing Content-Type ("content type") in this way as otherwise it can be used as a communication channel.

There's also the added problem that parsing of this header is not well-defined.

cc @achristensen07

@guohuideng2024
Copy link
Author

guohuideng2024 commented Mar 12, 2025

By-and-large this seems reasonable, but it really needs to have the same kind of minimization of information that we have in place for exposing Content-Type ("content type") in this way as otherwise it can be used as a communication channel.

There's also the added problem that parsing of this header is not well-defined.

cc @achristensen07

The minimization of information is in place: the "content-encoding" value is filtered before being exposed.
And I have put the filtering in the fetch draft PR:
whatwg/fetch#1796

Would you guys let me know what is the "parsing of this header is not well-defined?". It looks like this is an existing problem before this proposal? It sounds like it's a problem that only applies to "content-encoding" header, but not the other headers. Why?
I am new to this field and I appreciate that someone can help me understand the problem better.

Maybe we could discuss these concerns in whatwg/fetch#1796?
I am eager to move PR 1796 forward because some team is waiting for the feature to be available, and it's been 3 months already since I started working on the PR :(

[Edit 03/14/2025]: If there is something you guys think I can help with, I would be happy to make improvements. I do need some guidance from experts though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants