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

Hey folks!

This is something I think Chrome will be able to implement in Q1. To that
end, I'd like to come to some sort of consensus about where we'd like to
see the standardization work take place.

My personal preference would be to have distinct documents that describe
the rationale, give use cases/examples, and define the header together in
one package so that developers get a reasonable understanding of the thing
in itself. But I don't feel so strongly about it that I wouldn't take
Ilya's advice to work with folks in the WHATWG to integrate these hints
into Fetch. Likewise, I'd be happy to take Mark's advice, and define them
here (either in Client Hints or in distinct document) and merely reference
them from Fetch. I'm sure there are other constellations that might make
sense.

Since this group is currently responsible for both `User-Agent` and
`Accept-Language`, I'd appreciate y'all's advice on how you'd like me to
proceed.

Thanks!

-mike

On Wed, Dec 5, 2018 at 3:08 PM Ilya Grigorik <igrigorik@google.com> wrote:

> Hey folks.
>
> On Sat, Dec 1, 2018 at 7:48 PM Mark Nottingham <mnot@mnot.net> wrote:
>
>> Speaking personally --
>>
>> I could see splitting out the various task-specific bits into separate
>> documents (e.g., images).
>>
>> However, it's not good to ship a framework like this without having it
>> actually working for a real-world use case, so even if we split out all of
>> the various CHs into separate docs, I think we'd need to hold the "main"
>> document until at least one of those is ready.
>>
>> Just a thought -- replacing User-Agent is probably suitable for that test
>> case (in addition to the image-focused stuff, or perhaps instead of it). If
>> we do decide to do that, it might be suitable to put it in the core
>> document, since that seems like it's pretty central to what's going on here
>> (the current claims in the document about not replacing UA notwithstanding).
>>
>
> Just to clarify, we do have a shipping implementation of image hints
> (Viewport-Width, Width, DPR), as well as network related hints (ECT, RTT,
> Downlink). The latter set is defined in NetInfo [1] spec and the proposal
> is to spec processing definitions for image hints within Fetch+HTML to
> resolve current UA implementation and processing gaps — this would resolve
> and prevent questions similar to [2], [3]. On that note, the basic
> integration for image hints is already in Fetch (see steps 6+7 and related
> plumbing in [4]) but instead of linking to the IETF draft for definitions,
> the goal is to define those concepts directly against relevant HTML+Fetch
> concepts.
>
> Which is to say, this is editorial shuffling and it doesn't change or
> affect current shipping implementation of either sets of hints. I'm excited
> by Mike's proposal but I don't think we need to block the framework on that
> set of hints: we already have two existing shipping sets active in the wild.
>
> [1] https://wicg.github.io/netinfo/
> [2] https://github.com/httpwg/http-extensions/issues/698
> [3] https://github.com/httpwg/http-extensions/issues/697
> [4] https://fetch.spec.whatwg.org/#fetching
>
>
>> Chair hat on -- what I did notice was that when the update for CH was
>> read in Bangkok, *many* WG participants expressed surprise at the direction
>> you were taking it in; most people seemed to think that this document was
>> almost done in its current form, and there was concern that forming WG
>> consensus on that was being disregarded. So whatever you do here, please
>> make sure you get buy-in on the list, and make sure you coordinate with the
>> chairs. Continuing this discussion and moving towards a common idea of what
>> the doc(s) should include, when we should ship them, etc. sounds like a
>> good start.
>>
>
> Yup, fair feedback and will do. The change in course is based on recent
> discussions and issues that were raised as we were trying to shepherd the
> document through last stages.
>
> On Mon, Dec 3, 2018 at 1:49 AM Mike West <mkwst@google.com> wrote:
>
>> +Anne van Kesteren <annevk@annevk.nl> for the Fetch discussion. Hi, Anne!
>>
>> On Fri, Nov 30, 2018 at 6:00 PM Ilya Grigorik <igrigorik@google.com>
>> wrote:
>>
>>> +Mike West <mkwst@google.com> 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 <https://fetch.spec.whatwg.org/#default-user-agent-value>" (for `
>> navigator.userAgent
>> <https://html.spec.whatwg.org/#dom-navigator-useragent>`), and Fetch is
>> also responsible for setting the `User-Agent` value (in step 5.11 of
>> https://fetch.spec.whatwg.org/#http-network-or-cache-fetch). 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 `User-Agent`.
>>
>
> +Mike West <mkwst@google.com> yep, defining these in Fetch makes sense to
> me. I'll defer to the group on the deprecation.
>
> ig
>