Re: Migrating some high-entropy HTTP headers to Client Hints.

+Anne van Kesteren <> for the Fetch discussion. Hi, Anne!

On Fri, Nov 30, 2018 at 6:00 PM Ilya Grigorik <> wrote:

> +Mike West <> I like your proposal for User-Agent and
> Accept-Language. Most of the CH plumbing is already in place (or close to)
> in HTML spec, WDYT of defining those hints directly in the HTML spec?

For `User-Agent`: HTML currently relies on Fetch's "default `User-Agent`
value <>" (for `
navigator.userAgent <>`),
and Fetch is also responsible for setting the `User-Agent` value (in step
5.11 of That
seems like the right direction for the dependency, so I could imagine
defining the entire mechanism in Fetch if this group is willing to point
off in that direction in a future version of RFC7231 that deprecates

For `Accept-Language`, HTML defines `navigator.language{.s}
<>` with some
recommendations about what data to expose, and Fetch sets the header in
step 1.4 of Again, it seems
reasonable for the header work to be exposed in Fetch rather than pulling
it into HTML.

If we agree that these hints are interesting enough to build and ship, then
I'd be perfectly happy defining them in Fetch route, or doing something
like the drafts I sketched out above. The former approach would require
this group to point elsewhere when deprecating `Accept-Language` and
`User-Agent` in a future iteration of RFC7231, the latter requires some
discussion about which HTTPbis document they'd live in (see Mark's
suggestion to merge into the client hints draft itself). I have a personal
preference for small, focused, and separate documents (and I think Fetch is
already growing some features I'd have preferred to split out), but I also
don't have much context on the client hints discussion here thus far. I'm
happy to defer to y'all.


Received on Monday, 3 December 2018 09:49:23 UTC