Intent to Implement: Client-Hints header (DPR switching)

414 views
Skip to first unread message

Ben Greenstein

unread,
Sep 6, 2013, 2:55:20 PM9/6/13
to blin...@chromium.org
Primary eng (and PM) emails

be...@google.com


Spec

http://tools.ietf.org/html/draft-grigorik-http-client-hints-00


Summary

Client Hints can be used as input to proactive content negotiation; just as the Accept header allowed clients to indicate what formats they prefer, Client Hints allow clients to indicate a list of device and agent specific preferences. 

Motivation

New device form factors and screen DPRs are added to the market on a regular basis. Serving the same image resources to all devices (which may display them in differing dimensions and at different DPRs) is wasteful, and hurts Web performance.


This feature will allow the server to automatically pick and serve the best available resolution file without requiring any changes in the CSS or HTML markup of the page (hands-on example with nginx). 


Compatibility Risk

Low. This is a new feature. If the client does not support or advertise CH, or if the server does not support it, regular image (as implemented today) is served.


Ongoing technical constraints

None.


Is this feature supported on all five Blink platforms (Windows, Mac, Linux, Chrome OS and Android)?

Yes.


OWP launch tracking bug?

crbug: https://code.google.com/p/chromium/issues/detail?id=170388

Above CL is outdated and will be updated to focus on DPR-switching use case.

Row on feature dashboard?

Yes.


Darin Fisher

unread,
Sep 6, 2013, 2:57:30 PM9/6/13
to Ben Greenstein, blink-dev

Are any other browsers implementing this feature?

Ilya Grigorik

unread,
Sep 6, 2013, 3:45:25 PM9/6/13
to Darin Fisher, Ben Greenstein, blink-dev
On Fri, Sep 6, 2013 at 11:57 AM, Darin Fisher <da...@chromium.org> wrote:

Are any other browsers implementing this feature?

Not official commitments yet from other browsers. Having said that, I'm hoping we can make progress on that front at the responsive images meetup next week -- CH is a topic on the agenda

ig

Rik Cabanier

unread,
Sep 6, 2013, 4:42:49 PM9/6/13
to Ben Greenstein, blink-dev
For my own interest, does this impact caching on the client?
For instance, if I change my device pixel ratio or my screen size, will your patch invalidate the images that are in the browser cache?


To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Darin Fisher

unread,
Sep 6, 2013, 4:56:44 PM9/6/13
to Rik Cabanier, Ben Greenstein, blink-dev
Hmm, that reminds me...

We recently changed window.devicePixelRatio so that its value changes as a user zooms a page. Will that interact poorly with Client-Hints?

When I zoom in by 110% on desktop Chrome (running on Windows), I see window.devicePixelRatio reported as 1.100000023841858. Should that exact value be sent in the "CH: dpr=" HTTP request header?

-Darin

Emil A Eklund

unread,
Sep 6, 2013, 4:58:30 PM9/6/13
to Darin Fisher, Rik Cabanier, Ben Greenstein, blink-dev
On Fri, Sep 6, 2013 at 1:56 PM, Darin Fisher <da...@chromium.org> wrote:
> Hmm, that reminds me...
>
> We recently changed window.devicePixelRatio so that its value changes as a
> user zooms a page. Will that interact poorly with Client-Hints?
>
> When I zoom in by 110% on desktop Chrome (running on Windows), I see
> window.devicePixelRatio reported as 1.100000023841858. Should that exact
> value be sent in the "CH: dpr=" HTTP request header?

Ideally it should use the same value as window.devicePixelRatio. We
might want to round it to a couple of decimal points though.

Ilya Grigorik

unread,
Sep 6, 2013, 5:38:31 PM9/6/13
to e...@chromium.org, Darin Fisher, Rik Cabanier, Ben Greenstein, blink-dev

> When I zoom in by 110% on desktop Chrome (running on Windows), I see
> window.devicePixelRatio reported as 1.100000023841858. Should that exact
> value be sent in the "CH: dpr=" HTTP request header?

Ideally it should use the same value as window.devicePixelRatio. We
might want to round it to a couple of decimal points though.

Agreed. To go further, it may make sense to also increase it in some sensible multiples.. as to avoid creating too many cache key variants (at least while we're stuck with Vary).

Rik: If you rule out desktop zoom, then client cache is not affected -- yes, there will be an extra "Vary: CH", but since the dpr value is not changing, it's all the same entries. With desktop zoom, if the DPR changes, so does the cache key, and hence a new entry is created on the client (it wouldn't invalidate previously cached entries).

ig

Yoav Weiss

unread,
Sep 7, 2013, 10:34:56 AM9/7/13
to Ilya Grigorik, e...@chromium.org, Darin Fisher, Rik Cabanier, Ben Greenstein, blink-dev
I've updated Ben's patch at https://codereview.chromium.org/23654014 to bring it up to date.
I also removed the "dh" and "dw" hints, which are not part of this "Intent to implement", and fixed some issues.


Anne van Kesteren

unread,
Sep 9, 2013, 7:18:20 AM9/9/13
to Darin Fisher, Ben Greenstein, blink-dev
On Fri, Sep 6, 2013 at 7:57 PM, Darin Fisher <da...@chromium.org> wrote:
> Are any other browsers implementing this feature?

Given http://wiki.whatwg.org/wiki/Why_not_conneg I don't think this
will work out. Content negotiation works in environments where you
control both client and server and intermediaries don't get in the
way, otherwise it's just a mess.

And that's not even counting the fact that developers have massive
problems dealing with HTTP setups. Even something as simple as
Access-Control-Allow-Origin: * is too hard.


--
http://annevankesteren.nl/

Ilya Grigorik

unread,
Sep 9, 2013, 11:03:35 AM9/9/13
to Anne van Kesteren, Darin Fisher, Ben Greenstein, blink-dev
On Mon, Sep 9, 2013 at 1:18 PM, Anne van Kesteren <ann...@annevk.nl> wrote:
On Fri, Sep 6, 2013 at 7:57 PM, Darin Fisher <da...@chromium.org> wrote:
> Are any other browsers implementing this feature?

Given http://wiki.whatwg.org/wiki/Why_not_conneg I don't think this
will work out. Content negotiation works in environments where you
control both client and server and intermediaries don't get in the
way, otherwise it's just a mess.

Recent experience with Accept seems to show otherwise. We now have multiple large properties (both in and outside of Google) relying on content negotiation to serve appropriate image types -- and are doing this successfully without having to modify all the markup. It's about time we dispel the "HTTP negotiation doesn't work" myth!
 
ig

William Chan (陈智昌)

unread,
Sep 9, 2013, 11:25:47 AM9/9/13
to Ilya Grigorik, Anne van Kesteren, Darin Fisher, Ben Greenstein, blink-dev
Which properties? Are these all HTTPS based? Would love to know how successful content negotiation is in the clear. And I am curious how much of this is a property of the specific axis of content negotiation. We've had some amount of difficulty in the past with A-E.
 
 
ig

Ilya Grigorik

unread,
Sep 9, 2013, 11:38:19 AM9/9/13
to William Chan (陈智昌), Anne van Kesteren, Darin Fisher, Ben Greenstein, blink-dev

On Mon, Sep 9, 2013 at 5:25 PM, William Chan (陈智昌) <will...@chromium.org> wrote:
Which properties? Are these all HTTPS based? Would love to know how successful content negotiation is in the clear. And I am curious how much of this is a property of the specific axis of content negotiation. We've had some amount of difficulty in the past with A-E.

For Google properties, yes, with HTTPS -- the most recent one (may not be at 100% yet) being G+. Outside of Google.. globo.com (on homepage, and working on rollout across site), causes.com, ..., also cloudinary.com and cdnconnect.com offer it to their customers via Accept.

Anne van Kesteren

unread,
Sep 9, 2013, 11:50:38 AM9/9/13
to Ilya Grigorik, Darin Fisher, Ben Greenstein, blink-dev
On Mon, Sep 9, 2013 at 4:03 PM, Ilya Grigorik <igri...@google.com> wrote:
> Recent experience with Accept seems to show otherwise. We now have multiple
> large properties (both in and outside of Google) relying on content
> negotiation to serve appropriate image types -- and are doing this
> successfully without having to modify all the markup. It's about time we
> dispel the "HTTP negotiation doesn't work" myth!

That you have limited success in the case where you control both
client and server is not surprising, and I already acknowledged that
could be the case. Especially if this is for a single format choice.
WebP I guess? I don't think that really proves anything for the
general case though.


--
http://annevankesteren.nl/

Darin Fisher

unread,
Sep 9, 2013, 12:01:17 PM9/9/13
to Anne van Kesteren, Ilya Grigorik, Ben Greenstein, blink-dev
One thing that has changed over the years is that browser caches generally have much better support for the Vary header. Ignoring the configuration challenges (b/c I think those can be overcome if the incentives are strong enough), the main thing I was worried about is that content negotiation would defeat caching.

It used to be the case that a Vary response header would cause browsers to not cache a response, but now-a-days this is only true of old versions of IE, and it is possible for proxy caches to blacklist those versions of IE, such that they only see a particular response. I think it is intriguing to imagine how content negotiation can be used successfully by proxy caches thanks to the Vary header.

-Darin

William Chan (陈智昌)

unread,
Sep 9, 2013, 12:02:09 PM9/9/13
to Anne van Kesteren, Ilya Grigorik, Darin Fisher, Ben Greenstein, blink-dev
But Ilya says it's not just Google servers. For example, CDNConnect http://blog.netdna.com/developer/how-to-reduce-image-size-with-webp-automagically/. I think it's unfair to claim that "you control both client and server" in this case, unless I'm missing something.

And, if I understand correctly, the content negotiation here is being done with the new Client-Hints header. I think using a new header has significantly lower risk of intermediaries barfing on it, since people use new headers all the time, so the default intermediary behavior is to ignore it.

Adam Barth

unread,
Sep 9, 2013, 12:10:20 PM9/9/13
to William Chan (陈智昌), Anne van Kesteren, Ilya Grigorik, Darin Fisher, Ben Greenstein, blink-dev
On Mon, Sep 9, 2013 at 9:02 AM, William Chan (陈智昌) <will...@chromium.org> wrote:
But Ilya says it's not just Google servers. For example, CDNConnect http://blog.netdna.com/developer/how-to-reduce-image-size-with-webp-automagically/. I think it's unfair to claim that "you control both client and server" in this case, unless I'm missing something.

And, if I understand correctly, the content negotiation here is being done with the new Client-Hints header. I think using a new header has significantly lower risk of intermediaries barfing on it, since people use new headers all the time, so the default intermediary behavior is to ignore it.

That might be true in the short run, but it's important to consider the long run as well.

Adam

William Chan (陈智昌)

unread,
Sep 9, 2013, 12:11:34 PM9/9/13
to Darin Fisher, Anne van Kesteren, Ilya Grigorik, Ben Greenstein, blink-dev, Mark Nottingham
+mnot

This reminds me that unless we really want C-H to only ever contain one hint, we really need to finish up the HTTP Key work (http://tools.ietf.org/html/draft-fielding-http-key-00).

Ilya Grigorik

unread,
Sep 9, 2013, 4:10:36 PM9/9/13
to William Chan (陈智昌), Darin Fisher, Anne van Kesteren, Ben Greenstein, blink-dev, Mark Nottingham

On Mon, Sep 9, 2013 at 6:11 PM, William Chan (陈智昌) <will...@chromium.org> wrote:
This reminds me that unless we really want C-H to only ever contain one hint, we really need to finish up the HTTP Key work (http://tools.ietf.org/html/draft-fielding-http-key-00).

On a related note, there's been a flurry of GitHub activity in past few days discussing CH opt-in / separate header pros and cons, plus other related topics. A few threads that might be of interest (and please chime in):


ig

T.V Raman

unread,
Sep 9, 2013, 4:53:55 PM9/9/13
to igri...@google.com, ann...@annevk.nl, da...@chromium.org, be...@google.com, blin...@chromium.org
1+ on content-negotiation is worth revisiting. From memory, the
early browsers -- I'm thinking early == mid-90's here -- ensured
that content-negotiation started off being doomed by sending
out an accept: */* -- primarily to make sure that the server
sent them things they had just implemented --- at the time
browsers were moving fast --- and I suspect there was a desire
to avoid having the server "not expose some available contetn".

Christian Biesinger

unread,
Oct 25, 2013, 9:34:01 PM10/25/13
to T.V Raman, Ilya Grigorik, ann...@annevk.nl, Darin Fisher, Ben Greenstein, blink-dev, Philip Rogers
An update on this thread:
- Client hints (CH-DPR, the client-sent header) was implemented,
though on the chromium side --
https://codereview.chromium.org/24451003
- I have a pending CL to also implement the DPR header (send by the
server), as specified in
https://github.com/igrigorik/http-client-hints/blob/master/draft-grigorik-http-client-hints-01.txt#L255

My CL is blink-side, https://codereview.chromium.org/46313002/

-christian

Ilya Grigorik

unread,
Dec 6, 2013, 12:15:28 PM12/6/13
to Christian Biesinger, T.V Raman, Anne van Kesteren, Darin Fisher, Ben Greenstein, blink-dev, Philip Rogers
Quick update..  I've pushed an updated CH draft (01) to the IETF tracker:

Functionally there isn't anything new in there, it's all editorial changes and cleanup. If you have any feedback/knits, please let know, and/or open a ticket on GH: https://github.com/igrigorik/http-client-hints

In other news, Client-Hints discussion on Mozilla's tracker:
Reply all
Reply to author
Forward
0 new messages