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

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

Received on Wednesday, 5 December 2018 14:09:07 UTC