Re: Are we in favour of implementing the client hints header?

[Ilya Grigorik]

On Tue, Mar 8, 2016 at 5:05 AM, Xidorn Quan  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  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.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Are we in favour of implementing the client hints header?

[Jonas Sicking]

I filed

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

/ Jonas

On Thu, Mar 10, 2016 at 3:07 PM,   wrote:
> Hey Jonas,
>
> Please feel free to raise issues:
>   https://github.com/httpwg/http-extensions/labels/client-hints
>
> Cheers,
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Are we in favour of implementing the client hints header?

[mnot]

Hey Jonas,

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

Cheers,
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Are we in favour of implementing the client hints header?

[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


On Tue, Mar 8, 2016 at 3:21 PM, Martin Thomson  wrote:
> On Wed, Mar 9, 2016 at 6:42 AM, Jonas Sicking  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
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Are we in favour of implementing the client hints header?

[Martin Thomson]

On Wed, Mar 9, 2016 at 6:42 AM, Jonas Sicking  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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Are we in favour of implementing the client hints header?

[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  wrote:
> On Tue, Mar 8, 2016 at 7:40 PM, Gervase Markham  wrote:
>
>> 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?
>>
>
> 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-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Are we in favour of implementing the client hints header?

[Xidorn Quan]

On Tue, Mar 8, 2016 at 7:40 PM, Gervase Markham  wrote:

> 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?
>

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-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Are we in favour of implementing the client hints header?

[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


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform