Define more precisely which CH headers are sent by default

[sicking]

The spec currently says that clients should send CH headers "based on their default settings, user configuration and/or preferences". This needs to be more precisely defined in order to not cause interoperability problems between browsers.

I know that there's a tension between not sending too much header data which is commonly not used by servers, thus wasting bandwidth, while also sending enough information that servers can optimize their responses. However leaving the decision out of the spec and up to clients, doesn't make the problem simpler, it just pushes it onto someone else.

What I propose is the following:
For "document" loads, i.e. when browsers make the request during navigation, send the information which is typically needed for websites to determine what markup to serve. So things that let the server choose which version of a responsive-design page to serve first. I'd think this includes things like "viewport-width", "downlink" and "save-data". (We might also want to send other information like, is the device touch-enabled, but that's a separate discussion I think).

For non-"document" loads, serve no CH headers by default and instead let the "document" response opt in to which headers should be served for the non-"document" requests within that document. See also issue #155.

[igrigorik]

One plausible plumbing approach, borrowing from referrer policy:

• Every settings object has a client hints policy which governs the client hints information sent along with requests. The policy is null if no policy has been set.
  • note: we'll have to define how to parse and set it as part of CH draft, I guess.
• In Fetch... "A request has an associated client hints policy".
• In Fetch, as part of HTTP-network-or-cache fetch:
  • If the request is a navigation request, send:
    • Downlink, if known
    • Save-Data, if enabled
    • DPR
    • Viewport-Width
  • Otherwise, send client hints headers set by the client hints policy.

WDYT? I think that would solve both #155 and #156. The one notable change here, compared to what we've already shipped in Chrome is the "on by default" policy for navigation requests for Downlink + Viewport-Width hints.

/cc @annevk @yoavweiss

[sicking]

Yes, that seems like a good approach. And yes, CH needs to define how to parse and set the "client hints policy". Or at least some spec needs to before CH is implementable.

[mnot]

So, Fetch gets updated every time a new hint is defined?

[martinthomson]

Do we have an easy way of identifying them as hints so that it would be unnecessary to do that?

[igrigorik]

@mnot @martinthomson do you think that's a no-go? FWIW, I think the number of headers is relatively small and being explicit is OK in this instance.. I can imagine cases where we might want to define a header that's not automatically treated as "simple header".

[mnot]

I think it's OK if every time we create a new hint, we update Fetch (based on the anticipated number / volume).

[igrigorik]

In which case, the remaining question is: @annevk are you comfortable (re, whatwg/fetch#258) with integrating this as part of Fetch? I'm happy to draft the update. Alternatively, I guess I can try and monkey patch it from CH spec, but that's far less appealing..

[annevk]

Yeah, I am. It seems @hsivonen still has concerns with this entire feature, but if Mozilla will ship regardless (?) it sounds like that would be a good way to define all the edge cases here.

Another way to do this would be to patch the HTML Standard to set these headers as appropriate. Though the HTML Standard, especially the navigate algorithm, still needs some work done so perhaps it's better to use Fetch (at least for now).

[martinthomson]

@hsivonen's complaints are pretty well grounded in hard experience with inconsistent implementation of these features and the consequences of that. If it comes back to User-Agent scapulimancy because these aren't widely implemented (or implemented incorrectly), then he can say I-told-you-so and the web will rot further.

In this case, I think that the advantage of having this information available at the server before the client has even seen the first byte is a reasonable argument for the headers.

[yoavweiss]

👍 to suggested Fetch integration

[igrigorik]

If anyone wants to follow along: whatwg/fetch#258 -- initial run at integrating CH and Fetch.

[igrigorik]

TODO from whatwg/fetch#258 (comment):

In your draft, should probably say they define the header field value. A header field consists of a name and a value.

[mnot]

Does anything else need to change in the client-hints spec for this, or can we close the issue?

[igrigorik]

@mnot we're still missing integration with HTML spec - see #155 (comment). I was using this as a tracker for that work, perhaps we should rename this one?

[igrigorik]

After discussing it some more.. The remaining integration work (#155 (comment)) is against the HTML spec, so I'll close this and open a tracking issue there.