Clarification on multiple Accept-CH headers, ACCEPT_CH and/or <meta http-equiv> tags

[nicjansma]

I would like to get some clarification on how multiple Accept-CH HTTP headers, ACCEPT_CH ALPS, and/or HTML <meta http-equiv=”Accept-CH” content=”...” /> tags interact. As far as I can tell, the documentation around this is unclear and I'd offer to improve it once the goals are understood.

In practice, in Chrome 110, I’ve found that any combination of Accept-CH headers and/or <meta http-equiv=”Accept-CH” content=”...” /> tags are additive. That is, any additional headers (on the same HTTP response) add to the set of any already-requested hints.

accept-ch: sec-ch-ua-bitness
accept-ch: sec-ch-ua-platform-version

Is equivalent to

accept-ch: sec-ch-ua-bitness, sec-ch-ua-platform-version

And those two Client Hint requests are what will be stored in the site data for future page requests.

In addition, <meta http-equiv=”Accept-CH” content=”...” /> tags are additive on top of the Accept-CH header, and will apply to the current page only (so won’t persist in the site’s data).

accept-ch: sec-ch-ua-platform-version
<meta http-equiv="accept-ch" content="sec-ch-ua-arch">

Is equivalent to requesting both: sec-ch-ua-arch, sec-ch-ua-platform-version

(for only the current page – sec-ch-ua-platform-version will be stored in the site’s data, and sec-ch-ua-arc will be added only for this page)

The one exception I’ve found is clearing client hints via a blank Accept-CH: header takes precedence over any other Accept-CH headers, essentially stopping all Client Hints on that request. Header order within a response didn’t matter. A <meta http-equiv=”Accept-CH” content=”...” /> tag in the HTML will still work (for that page’s requested hints).

Finally, if we add ACCEPT_CH ALPS frames into the equation, it looks like the RFC specifies they are additive to the page’s Accept-CH headers and tags (https://datatracker.ietf.org/doc/html/draft-davidben-http-client-hint-reliability#section-4.3). I haven’t been able to verify this though.

If the above understanding is correct, I would suggest a small note in the explainer documenting how multiple ACCEPT_CH frames, headers and/or tags interact with each other, for clarity. When reviewing the current explainer, it wasn't immediately obvious if the hints would overwrite each other (or be additive), especially between headers and <meta> tags. I’m happy to open a PR with suggested text if that would help.

[arichiv]

I agree we should clarify the behavior! I should be able to get a PR up next week.

[arichiv]

Given the way Delegate-CH works it seems reasonable to allow multiple and have it be well defined. I'm not sure it's possible to have multiple ACCEPT_CH frames, but even if it is we should disallow it in the spec. Accept-CH and Critical-CH headers can currently appear multiple times, but we should restrict this in the spec and prevent chrome from supporting this as the behavior can't be easily well defined. https://github.com/WICG/client-hints-infrastructure/pull/147

[yoavweiss]

Accept-CH and Critical-CH headers can currently appear multiple times, but we should restrict this in the spec

HTTP semantics mean that

Accept-CH: foo
Accept-CH: bar

is identical to Accept-CH: foo, bar. I don't think we should break it.

[eeeps]

[I know nothing about ALPS frames] Are frames guaranteed to arrive in order?

Even if they aren't, I don't think https://github.com/WICG/client-hints-infrastructure/compare/753be21855...f86af461d7#diff-5e793325cd2bfc452e268a4aa2f02b4024dd9584bd1db3c2595f61f1ecf7b985R265 is racy because they're defined to be purely additive? But it was a question that came to mind and I figured I'd ask it.

Related, is running the whole algorithm twice, possibly any different than running it once after concatenating the values?

[Tanych]

Multiple ALPS frames

The accept_frame format is: <origin, accept_ch_value> pairs. In chromium, if users sent multiple accept_ch_frame for the same origin, only the first one will take effect, the subsequent accept_ch value for same origins are consider no-op. We didn't do any merge or additive on the chromium quic session in network layer.

multiple accept_ch header

This is expect behavior accroding to rfc2068, I don't think we need to limit format like accept_ch: value1, value2.

[arichiv]

I updated the PR to note that multiple Delegate-CH, Accept-CH, and Critical-CH tags/headers are possible but that only one ACCEPT_CH frame may appear.

I'll add WPTs for the multiple Accept-CH and Critical-CH headers and might have to change behavior around cache clearing for Accept-CH.

[arichiv]

Following up with tests in: https://bugs.chromium.org/p/chromium/issues/detail?id=1422562