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

Showing 1-21 of 21 messages
Intent to Implement: Client-Hints header (DPR switching) Ben Greenstein 9/6/13 11:55 AM
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.


Re: [blink-dev] Intent to Implement: Client-Hints header (DPR switching) Darin Fisher 9/6/13 11:57 AM

Are any other browsers implementing this feature?

Re: [blink-dev] Intent to Implement: Client-Hints header (DPR switching) Ilya Grigorik 9/6/13 12:45 PM
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

Re: [blink-dev] Intent to Implement: Client-Hints header (DPR switching) Rik Cabanier 9/6/13 1:42 PM
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.

Re: [blink-dev] Intent to Implement: Client-Hints header (DPR switching) Darin Fisher 9/6/13 1:56 PM
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
Re: [blink-dev] Intent to Implement: Client-Hints header (DPR switching) Emil A Eklund 9/6/13 1:58 PM
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.
Re: [blink-dev] Intent to Implement: Client-Hints header (DPR switching) Ilya Grigorik 9/6/13 2:38 PM

> 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

Re: [blink-dev] Intent to Implement: Client-Hints header (DPR switching) Yoav Weiss 9/7/13 7:34 AM
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.


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

Re: [blink-dev] Intent to Implement: Client-Hints header (DPR switching) Anne van Kesteren 9/9/13 4:18 AM
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/
Re: [blink-dev] Intent to Implement: Client-Hints header (DPR switching) Ilya Grigorik 9/9/13 8:03 AM

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
Re: [blink-dev] Intent to Implement: Client-Hints header (DPR switching) William Chan (陈智昌) 9/9/13 8:25 AM
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

Re: [blink-dev] Intent to Implement: Client-Hints header (DPR switching) Ilya Grigorik 9/9/13 8:38 AM

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.
Re: [blink-dev] Intent to Implement: Client-Hints header (DPR switching) Anne van Kesteren 9/9/13 8:50 AM
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/
Re: [blink-dev] Intent to Implement: Client-Hints header (DPR switching) Darin Fisher 9/9/13 9:01 AM
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
Re: [blink-dev] Intent to Implement: Client-Hints header (DPR switching) William Chan (陈智昌) 9/9/13 9:02 AM
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.


On Mon, Sep 9, 2013 at 8:50 AM, Anne van Kesteren <ann...@annevk.nl> wrote:

Re: [blink-dev] Intent to Implement: Client-Hints header (DPR switching) Adam Barth 9/9/13 9:10 AM
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


On Mon, Sep 9, 2013 at 8:50 AM, Anne van Kesteren <ann...@annevk.nl> wrote:
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/

Re: [blink-dev] Intent to Implement: Client-Hints header (DPR switching) William Chan (陈智昌) 9/9/13 9:11 AM
+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).
Re: [blink-dev] Intent to Implement: Client-Hints header (DPR switching) Ilya Grigorik 9/9/13 1:10 PM

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
Re: [blink-dev] Intent to Implement: Client-Hints header (DPR switching) TV Raman 9/9/13 1:53 PM
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".
Re: [blink-dev] Intent to Implement: Client-Hints header (DPR switching) Christian Biesinger 10/25/13 6:34 PM
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
Re: [blink-dev] Intent to Implement: Client-Hints header (DPR switching) Ilya Grigorik 12/6/13 9:15 AM
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:
More topics »