Should each CH property be a separate header?

[guypod]

Conceptually, anything we add as a client-hint could have been added to the User-Agent instead. The reasons we don't do so are primarily:

1. The User-Agent field is a mess and its structure is not well standardized
2. We want to be able to Vary based on a CH field

We're (hopefully) addressing (1) through this very definition exercise.
However, by putting all hints into one header, we're setting ourselves up for a repeat of (2). Once we add more client hints, varying on the CH header would not be very useful.

If we get support for Key at some point, this may be a lesser issue, but for now we don't have a clear line of sight to get it.

What if we added a separate header for each client-hint instead, using a standard format? For instance:

GET /a.jpg HTTP/1.1
CH-DPR: 2
CH-FontSize: 3
...

This will allow us to use Vary on one or more of these fields for very little overhead, which will get even smaller with HTTP/2.

[yoavweiss]

I contemplated the same thing following #8 .

On the one hand, the bloat issue will be worse if more hints are added (5 extra bytes per extra hint).
On the other hand, this feels like premature optimization, especially if an opt-in mechanism is in place.
Working with Vary today, instead of waiting a few years for key support in intermediaries, is a huge advantage.

[kornelski]

I like the idea!

• It almost turns Vary into Key
• It doesn't require authors to parse the field, so there's less potential for getting it wrong (parsing is hard, so authors may just stick to lazy things like strpos("dw=320") used to detect mobile phone failing hilariously on 45" dw=3200 screens).

[igrigorik]

Splitting multiple variables into separate HTTP headers makes the deployment slightly easier with Vary, but I think it's insufficient, and maybe more of an unnecessary distraction. Let me elaborate:

If you assume that every CH-X header is a binary toggle, then Vary is fine: we can Vary: CH-X, CH-Y to compose a custom cache key. So far so good. Now, to take the case of DPR, what if I want to cache a specific asset for resolutions above 2.0? You can't express that with Vary - we'll just have to cache multiple version. With Key, we can use the parameter range to express this: Key: CH;pr=dpr[1.5:]. Alternatively, we can cache an asset for screens in certain range: Key: CH;pr=dw[320:640].

At the end of the day, I think this comes down to incentives: adoption of any spec is driven by the size of the problem it addresses. CH+Key will solve a big problem, and I think CH is one good example and incentive for vendors (browsers, proxies, etc) to get it on the agenda...

If we have Key, then splitting CH into CH-X's is an unnecessary distraction. Granted, you could adopt both approaches: (a) "splitting helps until we have Key", but (b) we need Key anyway.

P.S. As Yoav pointed out, much of this may be premature optimization as well.. I think we should understand which other variables should be transported by CH, as that will have implications for which mechanism works.

[guypod]

@yoavweiss an opt-in mechanism for the hints you're interested indeed mitigates this issue, but it couples the variance. For instance, if a future client hint may share something like its past TCP CWND size from this location, or its geo location, you would have to "Vary" based on them alongside DPR - and it's unlikely all of those factors matter for a given request.

@igrigorik I agree Key would be better, but it'll be years before it's widely supported, so I meant this conversation to focus on what we have until then.

In addition, while this may be premature, it's one of those things that will be hard to change later. If we define CH as having one header, it'll remain one header... So I do think it's important to decide on it now, doing our best to predict the future needs.

IMO an addition of 5 bytes that the website opted into (as per #8) is minor compared to the greater flexibility when using Vary.

[yoavweiss]

What I meant was that considering multiple headers as promoting bloat (for the extra 5 bytes per attribute) may be premature optimization, and that an opt-in mechanism can mitigate the above mentioned bloat. Also as @mnot pointed out at #8, savings can be made by truncating the "CH-" part and the hint names, which will render the bloat argument moot.

@guypod - I completely agree that opt-in will not resolve the variance issues (even though it may reduce them).

[igrigorik]

Following a few more discussions (in person and in related threads -- @mnot's comments were especially compelling: #8 (comment)), took a cut at redefining CH as a set of independent headers:

• https://github.com/igrigorik/http-client-hints/blob/bc5822a29a21c0486879b691bf3a0d320eb8d083/draft.md#the-ch-name-request-header-field
• https://github.com/igrigorik/http-client-hints/blob/bc5822a29a21c0486879b691bf3a0d320eb8d083/draft.md#pre-defined-hints

This is all still experimental but any comments and suggestions are welcome.

[jonathantneal]

+1 @igrigorik I dig it. After thinking about it for a week, how do you feel?

[igrigorik]

New draft is using CH-{name} fields, and Chrome is advertising CH-DPR... closing this bug.

P.S. Thanks everyone for great feedback!