Are we in favour of implementing the client hints header?

[Andrew Overholt]

Implement Client-Hints HTTP header
https://bugzilla.mozilla.org/show_bug.cgi?id=935216

[Gervase Markham]

On 08/03/16 06:22, Andrew Overholt wrote:
> Implement Client-Hints HTTP header
> https://bugzilla.mozilla.org/show_bug.cgi?id=935216

Well, we are in favour of adaptive content, progressive enhancement,
responsive images in HTML, and feature detection. The question is
whether we think that these things cover all the use cases or not.

Do we know whether anyone's using this in Chrome?

Gerv

[Xidorn Quan]

Chrome Platform Status has items for this feature:
ClientHintsContentDPR:
https://www.chromestatus.com/metrics/feature/timeline/popularity/906
ClientHintsDPR:
https://www.chromestatus.com/metrics/feature/timeline/popularity/835
ClientHintsMetaAcceptCH:
https://www.chromestatus.com/metrics/feature/timeline/popularity/904
ClientHintsResourceWidth:
https://www.chromestatus.com/metrics/feature/timeline/popularity/836
ClientHintsViewportWidth:
https://www.chromestatus.com/metrics/feature/timeline/popularity/837

So it seems there were some websites tried to use this, which made its
usage up to 0.06%, but then they abandoned. All of the features above is
used only in ~0.0002% of pages surveyed now, which may indicate its
unpopularity. Not sure why it was ever used in 0.06% of pages, and why
those page abandoned it. Probably Chrome team knows.

- Xidorn

[Jonas Sicking]

I think the idea is a good one in general, though it would be good to
get data from Google on how it's been used in practice.

It's been quite a while since I reviewed the spec, so my thoughts
below might be outdated (or I might be misremembering).

There were two things that I found unfortunate about the spec.

One was that it was a bit undefined exactly which headers to include
when. This should not be left up to UA policy, but should be clearly
defined in spec.

The spec seemed too focused on including CH headers when loading
subresources of a page. Too few headers were included when loading the
"document" (in practice, when loading the HTML). My understanding is
that UA-sniffing is quite often used to determine what HTML to serve
to a given client, which I was hoping that CH could help reduce.

I know there's some concern that always sending CH with all requests
would generate too much header traffic which would be wasteful.
However I think something like the following could work:

* Include most headers during a navigation when loading a "document".
(In gecko terms, when the nsIContentPolicy-type is TYPE_DOCUMENT or
TYPE_SUBDOCUMENT).
* Default to no CH headers being sent for other requests.
* Make it possible for the document response to opt in to which
headers should be sent for resource loads that happen inside that
document. (In gecko terms, for requests which have a loadingNode that
belongs to the given document)

/ Jonas

On Tue, Mar 8, 2016 at 5:05 AM, Xidorn Quan <quanx...@gmail.com> wrote:
> On Tue, Mar 8, 2016 at 7:40 PM, Gervase Markham <ge...@mozilla.org> wrote:
>

> Chrome Platform Status has items for this feature:
> ClientHintsContentDPR:
> https://www.chromestatus.com/metrics/feature/timeline/popularity/906
> ClientHintsDPR:
> https://www.chromestatus.com/metrics/feature/timeline/popularity/835
> ClientHintsMetaAcceptCH:
> https://www.chromestatus.com/metrics/feature/timeline/popularity/904
> ClientHintsResourceWidth:
> https://www.chromestatus.com/metrics/feature/timeline/popularity/836
> ClientHintsViewportWidth:
> https://www.chromestatus.com/metrics/feature/timeline/popularity/837
>
> So it seems there were some websites tried to use this, which made its
> usage up to 0.06%, but then they abandoned. All of the features above is
> used only in ~0.0002% of pages surveyed now, which may indicate its
> unpopularity. Not sure why it was ever used in 0.06% of pages, and why
> those page abandoned it. Probably Chrome team knows.
>
> - Xidorn

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

[Martin Thomson]

On Wed, Mar 9, 2016 at 6:42 AM, Jonas Sicking <jo...@sicking.cc> wrote:
> I know there's some concern that always sending CH with all requests
> would generate too much header traffic which would be wasteful.

We could limit the feature to h2. (Which would also address the other
request, which is to limit this to https://)

I'm surprised that the CORS interaction hasn't been raised:
https://github.com/httpwg/http-extensions/issues/141

[Johnny Stenback]

Based on what I know I'm not opposed to implementing this feature from
the point of view of whether this would be good for the web or not.
What I'd question is whether this is good use of our time given the
platform team's current focus on quality.

- jst

[mn...@mnot.net]

Hey Jonas,

Please feel free to raise issues:
https://github.com/httpwg/http-extensions/labels/client-hints

Cheers,

[Jonas Sicking]

I filed

https://github.com/httpwg/http-extensions/issues/155
https://github.com/httpwg/http-extensions/issues/156

/ Jonas

[Henri Sivonen]

On Tue, Mar 8, 2016 at 8:22 AM, Andrew Overholt <over...@mozilla.com> wrote:
> Implement Client-Hints HTTP header
> https://bugzilla.mozilla.org/show_bug.cgi?id=935216

Client-Hints is negotation on the HTTP layer that goes beyond
reversible bit transformation (i.e. it's not like gzip or Brotli). I
continue to believe that negotation mechanisms that the layout part of
the engine is aware of are superior to pushing the negotiation to the
networking layer. See https://wiki.whatwg.org/wiki/Why_not_conneg for
an example how the <source> children of <video> and <audio> are
superior to HTTP-layer negotation (although https is making non-CDN
proxies irrelevant).

So I continue to think that Client-Hints is architecturally bad. For
images, <picture> and srcset exist and are superior. For CSS, I
continue to think we should add a mechanism for <link rel=stylesheet>
to opt out of synchronous CSSOM and sheets that opt out of synchronous
CSSOM and whose media query doesn't match should not be fetched.

I continue to be opposed to Client-Hints as far as the merits of the
feature go. However, I prioritize Web compat over good architecture,
so if sites deploy Client-Hints to Chrome such that it becomes a Web
compat problem for us, I think we should probably implement the
feature to neutralize the Web compat threat.

--
Henri Sivonen
hsiv...@hsivonen.fi
https://hsivonen.fi/

[Ilya Grigorik]

On Tue, Mar 8, 2016 at 5:05 AM, Xidorn Quan <quanx...@gmail.com> wrote:

> So it seems there were some websites tried to use this, which made its
> usage up to 0.06%, but then they abandoned. All of the features above is
> used only in ~0.0002% of pages surveyed now, which may indicate its
> unpopularity. Not sure why it was ever used in 0.06% of pages, and why
> those page abandoned it. Probably Chrome team knows.
>

I'm suspect of those histograms as many of them take a deep dive around our
M49 release. Wondering if we botched something on our end -- I'll
investigate.

That said, now that we've had this out in the wild for a while, some
learnings and feedback:

1) In Chrome we've intentionally restricted initial implementation to apply
to subresource requests only - i.e. navigation requests do not get any
hints but can opt in their subresources. This decision was mostly a
defensive move: we didn't want to send lots of new headers all at once to
every site on the web; we wanted sites to opt-in and test their
infrastructure. However, as Jonas already noted, said mechanism means that
sites (a) can't detect client support for hints and (b) have continue to
rely on UA sniffing (both for hints and the values that the hints
communicate -- yes, it is ironic :)). This particular limitation came up in
most every conversation I've had with various teams experimenting with CH,
and was a roadblock for many.

Addressing the above would go a long way. If you want to follow along, see:
https://github.com/httpwg/http-extensions/issues/156

2) Re, CORS: this has been an ongoing discussion, but I think we're getting
close. Opened: https://github.com/whatwg/fetch/pull/258

3) Chrome / Opera / Yandex are close to shipping Save-Data [1], which does
not require Accept-CH opt-in; all three browsers will advertise Save-Data
whenever the user enables ~"reduce data usage" mode in the browser. While
it's still early, I can definitely say that removing the opt-in requirement
has helped drum up *a lot* more interest.

Aside: are there any user prefs in Firefox that could or should enable
Save-Data?

[1] https://developers.google.com/web/updates/2016/02/save-data

On Thu, Mar 17, 2016 at 3:00 AM, Henri Sivonen <hsiv...@hsivonen.fi> wrote:
>
> I continue to believe that negotation mechanisms that the layout part of
> the engine is aware of are superior to pushing the negotiation to the
> networking layer.
>

That may well be true, but as we've discussed before, there are valid use
cases where negotiation can: significantly lower the adoption barriers and
complexity through automation; enable better data savings; address the
myriad of UA-sniffing hacks that developers have to rely on today. Which is
to say, they're not exclusive, and I don't think we should consider them as
one vs. the other.

---

In short, based on the experience so far, the overall feedback I've had has
been positive, but we do need to address some of the shortcomings in the
current design, as outlined above. With that in place, I think we'll
unblock a lot of interesting use cases.