Re: [w3ctag/design-reviews] Expose contentEncoding in resourceTiming (Issue #1064)

guohuideng2024 left a comment (w3ctag/design-reviews#1064)

> Just on this last point, I might prefer that you omit the content coding if it is unknown, rather than picking a new type of label. I know that this makes it hard to distinguish between a browser that supports this and one that doesn't, but we should try to avoid building systems that use special flag values. (It's also possible to supply a value of `null` in JSON, if you want to solve that distinguishing problem.)
> 
> [HTTP WG Thread](https://www.w3.org/mid/SA6PR00MB22464C271F327625DFA6ACBAC0812@SA6PR00MB2246.namprd00.prod.outlook.com)

Actually, a legitimate and functional compression can be a proprietary compression handled by server worker. The `@unknown` actually means "there is a content-encoding, but for privacy/security reason, you cannot see what it is", instead of "there is a rejected and failed compression that you may not care about".

And there is strong need from the app devs. See:
https://github.com/w3c/resource-timing/issues/381#issuecomment-2543556731

We members of WebPerf WG spent quite a bit of time trying to decide what the value would be. The consensus is that we like to have a string literal that is descriptive (preferrable over `null`). I tried to register/reserve the value `unknown` at HTTP working group. (The purpose is to prevent someone in future from creating a compression called "unknown", which is not able to be exposed properly.) After some discussion with folks in HTTP working group, we decided on `@unknown` because `@unknown` cannot be a `content-coding` value due to syntax violation. 

I am sorry I didn't put the details in the explainer. It's very confusing. Do you think I should add these details to the explainer?



-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1064#issuecomment-2935787104
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1064/2935787104@github.com>