Open Bug 935216 (client-hints) Opened 11 years ago Updated 2 months ago

Implement Client-Hints HTTP header

Categories

(Core :: Networking: HTTP, enhancement, P5)

Product:
Core
Component:
Networking: HTTP
Platform:
x86
All
Type:
enhancement

Tracking

()

Status:
UNCONFIRMED
Tracking Flags:
Tracking Status
platform-rel --- +

People

(Reporter: igrigorik, Unassigned)

References

(Blocks 2 open bugs,
URL
)

Details

(Keywords: dev-doc-needed, Whiteboard: [necko-would-take][platform-rel-Shopify])

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.101 Safari/537.36 Steps to reproduce: Client-Hints is a mechanism for proactive content negotiation: client advertises some set of hints via HTTP request header, server uses provided hints to adapt the served resource - as such, it's a generic mechanism that can be extended to any number of use cases. That said, one of the primary motivators for CH today is to help automate (where possible) the negotiation of optimal resolution and size of delivered image resources. For a quick intro: https://github.com/igrigorik/http-client-hints. - v1 spec draft: https://github.com/igrigorik/http-client-hints/blob/master/draft-grigorik-http-client-hints-01.txt - for server folks: https://github.com/igrigorik/http-client-hints/tree/master/server Chrome Canary has CH-DPR implemented behind a flag (see instructions in link above): this includes sending the CH-DPR header, and also using DPR value provided by the server to adjust the intrinsic size calculation of the image. The end result is that this provides an automated way to perform resolution-switching, which is one of the major use cases for responsive images. It's also worth noting that CH provides clean interop with / simplifies src-N and srcset (whichever one wins) - for a hands on example with src-N see [1], for srcset it similarly automates the "x" queries. Finally, for those who read earlier drafts, a quick recap of updates in new draft: - Hints are sent in different headers (e.g. CH-DPR: 2.0) - this allows better interop with existing caches [2] - New "server confirmation" header (e.g. "DPR: 1.5") allows server to indicate the DPR of served resource, which is then used to adjust intrinsic size calculations on the client. [3] - "Device width" has been replaced with "Resource display width" (CH-RW.. in DIPs) [4] - There is an opt-in mechanism defined that allows individual origins to trigger CH hints [5] Based on the implementation experience so far, the CH-DPR hint is well understood and looks solid - when enabled on the server it automates resolution-switching without any site modifications, which makes it very appealing for CDNs / optimizing proxies / image hosting services. The CH-RW hint is partly conditional on src-N and likely needs some more experimentation. It would be great to see CH support in FF! At a minimum, CH-DPR is a great place to start while we wait for srcset/src-N situation to get clarified. [1] https://github.com/igrigorik/http-client-hints#interaction-with-src-n [2] https://github.com/igrigorik/http-client-hints/issues/14 [3] https://github.com/igrigorik/http-client-hints/issues/13 [4] https://github.com/igrigorik/http-client-hints/blob/master/draft-grigorik-http-client-hints-01.txt#L239 [5] https://github.com/igrigorik/http-client-hints/blob/master/draft-grigorik-http-client-hints-01.txt#L310
URL: https://github.com/igrigorik/http-cli...
See Also: → srcset
Severity: normal → enhancement
OS: Mac OS X → All
Component: Untriaged → DOM
Product: Firefox → Core
Component: DOM → Networking: HTTP
Jonas, I thought we had objections to this whole mechanism?
Flags: needinfo?(jonas)
Ilya and the rest of the community have been working hard to overcome the concerns originally raised by folks at Mozilla. I personally think we should give this another look; particularly as, together with src-n, it gives a coherent story that solves many responsive images use cases (without forcing anyone into doing conneg because it's now opt-in).
I like this approach. Though we should run it by the necko team and Patrick McManus in particular to get feedback on if the extra headers is a concern bandwidth-wise. The big question is which headers to add. I've tried to see if any of the headers here could help reduce UA-sniffing when determining to send desktop vs. tablet vs. mobile apps. CC'ing people that can help inform us there.
Flags: needinfo?(jonas)
Re, other signals: would love to hear what other headers / values would be useful. So far, the one request I've heard is for indicating touch support: https://github.com/igrigorik/http-client-hints/issues/12 For responsive images, I believe CH-DPR and CH-RW should be sufficient.
About "CH-RW:", what is happening for the next requests if you rotate the device?
Karl: assuming we're using "Vary: CH-RW" to signal that the resource has been optimized for previous hint, next time the resource width has changed and a request is made, it would skip the UA's HTTP cache and fetch a different version of the asset (as a result, both would be cached independently under two different cache keys). In some cases, the above workflow is suboptimal.. Vary is too blunt of a tool. Ideally, we'd have more granular control to describe how/when the cached resource should be used -- this is what mnot's Key proposal is trying to solve [1]. [1] https://github.com/igrigorik/http-client-hints/blob/master/draft-grigorik-http-client-hints-01.txt#L353
(In reply to Ilya Grigorik from comment #0) > Based on the implementation experience so far, the CH-DPR hint is well > understood and looks solid - when enabled on the server it automates > resolution-switching without any site modifications, which makes it very > appealing for CDNs / optimizing proxies / image hosting services. The CH-RW > hint is partly conditional on src-N and likely needs some more > experimentation. I think one of the bigger challenges of any alternative to UA databases is getting adoption. Can you comment on any sites/CDNs with which you've been working who have implemented this solution (as a test)?
PageSpeed team is definitely interested in supporting it, which would enable CH on: mod_pagespeed (Apache), ngx_pagespeed (nginx), IISpeed (Microsoft IIS), and Apache Traffic Server (all of which have pagespeed modules). As a bonus, it would also get enabled on PageSpeed Service (running on Google CDN).. all combined, that's 650K+ existing sites using PageSpeed and its derivatives. Same goes for other internal Google services - our image services would leverage it for our existing products. - resrc.it team implemented earlier draft [1] of CH, and I'm working with them to get new version up. - cdnconnect and cloudinary both expressed interest in CH as well. - many other/existing CDN services offer image manipulation/resizing as a service already, so this is just an incremental feature that would simplify/automate the workflow. Finally, you could, of course, just roll your own implementation in Apache/nginx/etc. I have some simple examples [2] checked into the CH GitHub repo. [1] https://twitter.com/ReSRCit/status/393349203742580736 [2] https://github.com/igrigorik/http-client-hints/tree/master/server
(In reply to Lawrence Mandel [:lmandel] from comment #7) > I think one of the bigger challenges of any alternative to UA databases is > getting adoption. Can you comment on any sites/CDNs with which you've been > working who have implemented this solution (as a test)? As a CDN which already does dynamic image manipulation via querystrings, I can say that also setting parameters (such as DPR) through a request header, along with a few cache key config changes, is a relatively simple implementation. CDNConnect should have this feature up shortly.
Note that Akamai already supports making all sorts of traffic manipulations based on incoming headers, and we do so all the time. There should be no problem responding to new CH-* headers on Akamai, and we can easily combine it with our Image Converter product to resize images accordingly. Given enough demand, we can easily create pre-packaged rules in our Property Manager for triggering this combination (again a common occurrance).
We at Mobify are also interested in CH as another way of doing dynamic image manipulation with our service (http://ir0.mobify.com / mobify.js).
As a heads up, I've pushed an updated draft (01) to the IETF tracker: http://tools.ietf.org/html/draft-grigorik-http-client-hints-01 That said, functionally there isn't anything new in there, it's all editorial changes and cleanup (thanks Mark!). If you have any feedback/knits, please open a ticket on GH: https://github.com/igrigorik/http-client-hints
The way to support responsive design that would be consistent with the rest of the platform would be extending the <img> element (multiple proposals available), adding away for the page to opt out of CSSOM access to allow the browser not to download inapplicable stylesheets and using Media Queries. A solution based on those higher levels in the stack would work for cases like rotating a handheld device after page load on mobile and adapting the page to desktop-style zooming that changes the device pixel ration after loading. It would also work for Firefox OS packaged apps that load from a zip file instead of loading from an HTTP server. I think it would be sad if we ended up supporting an HTTP-layer hack instead of one of the HTML-level Responsive Image designs and a way for the page to opt out of CSSOM access just because there was a better availability of networking developer time compared to layouts developer time and that the HTML-level Responsive Image proposals were too fragmented for use to have the confidence to pick one of them and implement. The way I see it (as neither a networking developer nor a layout developer), Client Hints is not the right solution when considering the platform as a whole, but it's something that allows networking developers to address the problem on the networking layer without having to deal with layout development or the HTML Responsive Image proposal mess. I would prefer we considered the platform as a whole and addressed the problem on layers closer to layout, since that's how the platform has dealt with similar things previously and since that would allow adaptation the change after the first HTTP request have already been done when the parameters change. I think limiting the adaptation to the moment in time where image (etc.) requests happen as part of the page load and then failing to adapt upon device rotation or desktop zoom is pretty crude compared to what we do with CSS. Also, unless I missed something that makes Client Hints something that servers have to opt into, Client Hints would be sent with every HTTP request. That's a lot of cruft to add in every HTTP request that we'll never be able to get rid of, and that's pretty scary even if right now the cruft didn't make requests grow too large considering packet sizes, congestion windows, etc. So I think we should not implement Client Hints and should instead: 1) Stop bikeshedding HTML-level Responsive Images and just implement one proposal. AND 2) Add a way for <link rel=stylesheet> to opt out of CSSOM so that the sheet is not fetched until its media query starts matching.
Henri, (In reply to Henri Sivonen (:hsivonen) from comment #13) > whole, but it's something that allows networking developers to address the > problem on the networking layer without having to deal with layout > development or the HTML Responsive Image proposal mess. Not exactly. Think about client hints in terms of UA sniffing. > I think limiting the adaptation to the moment in time where image (etc.) > requests happen as part of the page load and then failing to adapt upon > device rotation or desktop zoom is pretty crude compared to what we do with > CSS. The proposal is not to request images but to send device capabilities. It seems to me that it's independent of the images that would be requested in the end. The client says I'm this, and the server can negotiate a first answer instead of relying on a out-of-band UA database describing the capabilities of the device. > Also, unless I missed something that makes Client Hints something that > servers have to opt into, Client Hints would be sent with every HTTP > request. A few bytes compared to kb of images, CSS, etc. Plus with the coming of HTTP2, it means only on the first request because subsequent requests will be happening in the same session. So consider the proposal as you said taking into account the full picture and not only responsive images. Right now we are having plenty of requests, redirections, latency issues and failures because of UA sniffing. Most of the time this UA sniffing is happening because developers want to know if the device is a mobile device or not with its rudimentary capabilities. :) All of that said, there might be a better proposal. :) What would you imagine to solve it?
Given that people aren't changing just the image data, but rather the full UI, as the screen size changes, I don't think attempting to solve this using <img> would work. Additionally, having to add complicated syntax on each <img> that you want to adapt to screen resolution makes the web platform much more complicated for developers. I see this as the equivalent of feature-testing. But at the point where the decision should be made, i.e. on the server. Forcing all decisions to be made in the client means having to both upload much more logic into the client in each request, and forces a lot more complexity to live in the client. I do worry about the bandwidth issue too, however given that the network guys have said that this is ok, I think that's a strong argument not to worry.
(In reply to Henri Sivonen (:hsivonen) from comment #13) > The way to support responsive design that would be consistent with the rest > of the platform would be extending the <img> element (multiple proposals > available), adding away for the page to opt out of CSSOM access to allow the > browser not to download inapplicable stylesheets and using Media Queries. Agreed! We need a markup solution for responsive images and it would be great to have a way to opt-out from CSS downloads. CH doesn't preclude either mechanism, its aim is to simplify the common and repetitive case of resolution-switching by allowing the server to take care of this negotiation on your behalf. If you wish to go at it the manual way, that's cool. > A solution based on those higher levels in the stack would work for cases like > rotating a handheld device after page load on mobile and adapting the page > to desktop-style zooming that changes the device pixel ration after loading. > It would also work for Firefox OS packaged apps that load from a zip file > instead of loading from an HTTP server. Neither rotation or desktop-style zooming are any different with CH - if they are, that's something we can definitely fix. For packaged apps, you're right, you would probably have to lean on markup. > I think it would be sad if we ended up supporting an HTTP-layer hack instead > of one of the HTML-level Responsive Image designs and a way for the page to > opt out of CSSOM access just because there was a better availability of > networking developer time compared to layouts developer time and that the > HTML-level Responsive Image proposals were too fragmented for use to have > the confidence to pick one of them and implement. > > The way I see it (as neither a networking developer nor a layout developer), > Client Hints is not the right solution when considering the platform as a > whole, but it's something that allows networking developers to address the > problem on the networking layer without having to deal with layout > development or the HTML Responsive Image proposal mess. I would prefer we > considered the platform as a whole and addressed the problem on layers > closer to layout, since that's how the platform has dealt with similar > things previously and since that would allow adaptation the change after the > first HTTP request have already been done when the parameters change. Semantics, but I wouldn't characterize this as a hack. Content negotiation is a well defined feature in the protocol and one that can simplify the lives of many developers in this instance. The fact that can we can enable hundreds of thousands-millions of sites overnight by flipping a switch on a few servers, to me, is well worth the effort. Once again, CH does not eliminate the need for a markup solution - I'm 100% with you there. > I think limiting the adaptation to the moment in time where image (etc.) > requests happen as part of the page load and then failing to adapt upon > device rotation or desktop zoom is pretty crude compared to what we do with > CSS. You've mentioned "allow adaptation after the first HTTP request" a few times: do you have a specific example where you see this breaking? FWIW, if the parameters change and a new layout rule is triggered which requires a different asset, then the request is made regardless of whether CH is present or not -- CH just eliminates some of the boilerplate in your markup. > Also, unless I missed something that makes Client Hints something that > servers have to opt into, Client Hints would be sent with every HTTP > request. That's a lot of cruft to add in every HTTP request that we'll never > be able to get rid of, and that's pretty scary even if right now the cruft > didn't make requests grow too large considering packet sizes, congestion > windows, etc. We have an opt-in mechanism to address this: http://tools.ietf.org/html/draft-grigorik-http-client-hints-01#section-2.3.1 In a nutshell, the server that supports CH would advertise this via a response header or an equivalent http-equiv attribute, and the UA would append the request hints for following subresources on that page. > 1) Stop bikeshedding HTML-level Responsive Images and just implement one proposal. Agreed. I think as most everyone on this thread, I'd love to see this resolved, and preferably yesterday! CH is not a replacement, its a way to automate parts of the larger problem. As of today, it specifically targets resolution switching, and once we have a better feel for the new <picture> proposal... we can revisit and see if CH makes sense in any other contexts. > 2) Add a way for <link rel=stylesheet> to opt out of CSSOM so that the > sheet is not fetched until its media query starts matching. Agreed, but I think this is mostly orthogonal to our discussion here. :-)
For information, checking the HTTP Requests headers of a couple of browsers today. I noticed that UCWeb is sending with every single requests. > X-UCBrowser-UA: pf(Linux);la(en-US);re(AppleWebKit/533.1 (KHTML, like Gecko));dv(GT-I9100 Build/GINGERBREAD);pr(UCBrowser/9.4.1.362);ov(Android 2.3.5);pi(480*762);ss(480*762);up(U3/0.8.0);er(U);bt(GJ);pm(1);bv(1);nm(0);im(0);sr(0);nt(2); Searching for more information about its meaning, I discovered: User-Agent and X-UCBrowser-UA Specification of UC Browser http://www.ucweb.com/download/UCBrowser_User_Agent_en.pdf Page 11, they describe their format: Key1(Value1);Key2(Value2); … * pf: platform * up: UC platform * er: encryption * la: language * re: rendering * dv: device * pr: product * ov: OS version * pi: pixel (width*height) * ss: density (width*height) * pm: proxy mode (off/on) * bv: browsing view (fit to screen, zoom view) * nm: night mode
Henri, are you satisfied with Ilya's response? Does it address your concerns?
Flags: needinfo?(hsivonen)
As a heads up, I've updated the docs with examples of CH + <picture> element interop: https://github.com/igrigorik/http-client-hints#interaction-with-picture-element Also, rescr.it implemented both CH-RW and CH-DPR support on their servers - yay! I've put together a quick example via XHR to show it in action: http://jsbin.com/EHAkiCa/1/quiet - if you open up the source, you'll see that it's the same resource being requested, just with different CH- parameters. Note that the images are intentionally shown in their "intrinsic" size.. I'm not rescaling them to match device DPR to show that they are, in fact, different assets. When requested through <img> or <picture>, the headers + resizing would be all automated.
(In reply to Marcos Caceres [:marcosc] from comment #18) > Henri, are you satisfied with Ilya's response? Does it address your concerns? Sorry about the delay. I failed to return this to my attention after the holidays. My concern about having to send the these headers to every site forever is addressed by the opt-in mechanism that I missed earlier. I think my other concerns still stand. (In reply to Karl Dubost :karlcow from comment #14) > (In reply to Henri Sivonen (:hsivonen) from comment #13) > > whole, but it's something that allows networking developers to address the > > problem on the networking layer without having to deal with layout > > development or the HTML Responsive Image proposal mess. > > Not exactly. Think about client hints in terms of UA sniffing. I think it's overly optimistic to expect client hints to replace UA sniffing. I expect this pattern to apply: 1) People are doing X. 2) X is bad for reasons A, B and C. 3) Y would solve A, B and C in a way that makes sense for the platform as a whole. 4) Z is the minimum change to X to address A, B and C. 5) Y is hard to implement/conceptually different, let's do Z! 6) Z gets implemented. 7) Old browsers don't support Z. 8) People keep doing X. With UA sniffing as X, responsive images and media queries as Y and CH as Z. > > I think limiting the adaptation to the moment in time where image (etc.) > > requests happen as part of the page load and then failing to adapt upon > > device rotation or desktop zoom is pretty crude compared to what we do with > > CSS. > > The proposal is not to request images but to send device capabilities. The ID has two hints: CH-DPR and CH-RW. CH-DPR is bitmap-oriented. CH-RW assumes that the HTTP request has a context where the concept of display width is relevant. In theory, there could be more hints in the future, but the ones being proposed now are pretty image-oriented! > > Also, unless I missed something that makes Client Hints something that > > servers have to opt into, Client Hints would be sent with every HTTP > > request. > > A few bytes compared to kb of images, CSS, etc. Plus with the coming of > HTTP2, it means only on the first request because subsequent requests will > be happening in the same session. Unfortunately, HTTP 1.x will be around for long time, so "HTTP2 fixes the problem being introduced here" is not a persuasive answer if the problem is actually a problem. Also, the request headers flow in a different direction than images, CSS, etc. > So consider the proposal as you said taking into account the full picture > and not only responsive images. Right now we are having plenty of requests, > redirections, latency issues and failures because of UA sniffing. Most of > the time this UA sniffing is happening because developers want to know if > the device is a mobile device or not with its rudimentary capabilities. :) I don't see how CH would solve this in practice. As proposed, http://tools.ietf.org/html/draft-grigorik-http-client-hints-01 does not include an "is mobile" hint. On the other hand, searching for the substring "Mobi" in the UA string is remarkably accurate and since all browsers will never support CH, even if CH added an "is mobile" hint, it could never surpass searching for the substring "Mobi" in the UA for accuracy. > What would you imagine to solve it? Either Web authors getting rid of the mindset that results in posing the question "Is this mobile?" or as long as the mindset is there, searching for the substring "Mobi" in the UA string. (In reply to Jonas Sicking (:sicking) from comment #15) > Given that people aren't changing just the image data, but rather the full > UI, as the screen size changes, I don't think attempting to solve this using > <img> would work. Since CH is now opt-in (which is better than it's not being opt-in!), you can't use it for changing the full UI in the sense of varying the outermost HTML document, since the request for the outermost HTML document happens without CH whenever the requesting HTTP stack is in a state where it doesn't have a CH opt-in cached. > Additionally, having to add complicated syntax on each <img> that you want > to adapt to screen resolution makes the web platform much more complicated > for developers. src-N isn't really that complicated for non-complicated designs. CH requires to change server-side program logic instead of just changing HTML or CSS when they want to adjust the design. (In reply to Ilya Grigorik from comment #16) > Neither rotation or desktop-style zooming are any different with CH - if > they are, that's something we can definitely fix. If you zoom on desktop, the device pixel ratio changes without all HTTP requests for the parts of the page getting replayed. If you change the window size on desktop or rotate the screen on mobile, the width of the weep or changes without all HTTP requests for the parts of the page getting replayed. So both cases are definitely different from how things would work with CH unless CH forces a reload upon rotate, window size change (hello Netscape 4!) or desktop zoom. > Semantics, but I wouldn't characterize this as a hack. Content negotiation > is a well defined feature in the protocol I think it's a misfeature for reasons stated in http://wiki.whatwg.org/wiki/Why_not_conneg > You've mentioned "allow adaptation after the first HTTP request" a few > times: do you have a specific example where you see this breaking? Upon rotate, window size change or desktop zoom, unless these imply re-issuing HTTP requests somehow. And, if these are meant to imply re-issuing the HTTP requests, then CH isn't actually a pure HTTP-layer feature and the impact on the higher layers needs to be specified and assessed (at which point we should really be putting the effort into client-side respimg and CSS OM opt-out instead). > FWIW, if > the parameters change and a new layout rule is triggered which requires a > different asset, then the request is made regardless of whether CH is > present or not -- CH just eliminates some of the boilerplate in your markup. If the DPR *response* header is to allow the client to figure out which images to reload upon zoom/window size change/rotate, the spec doesn't appear to be explicit about the expectation of resources getting selectively re-requested. > > Also, unless I missed something that makes Client Hints something that > > servers have to opt into, Client Hints would be sent with every HTTP > > request. That's a lot of cruft to add in every HTTP request that we'll never > > be able to get rid of, and that's pretty scary even if right now the cruft > > didn't make requests grow too large considering packet sizes, congestion > > windows, etc. > > We have an opt-in mechanism to address this: > http://tools.ietf.org/html/draft-grigorik-http-client-hints-01#section-2.3.1 I missed this before. Sorry. > CH is not a replacement, its a way to > automate parts of the larger problem. It automates them in a different place than a <picture>/src-N autogenerator and, as a result, afforts less opportunity for having the selection logic on the client. > > 2) Add a way for <link rel=stylesheet> to opt out of CSSOM so that the > > sheet is not fetched until its media query starts matching. > > Agreed, but I think this is mostly orthogonal to our discussion here. :-) Not as far as I can tell. CSS currently causing overfetching has been previously given as a reason to have server-side adaptation logic instead of relying on Media Query-based client-side logic. - - Comments on the current spec: The problems with UA sniffing mentioned in "Introduction" won't solve by Client Hints unless Client Hints can eradicate UA sniffing altogether. Since there will be browsers, especially zombied mobile ones, without Client Hints support for the foreseeable future, even if Client Hints gets adopted, chances are that sites will also use UA sniffing for older browsers, in which case they still require an external database and cause cache-unfriendliness. "Now you have two problems." The section "Sending Client Hints" basically says "anything goes" which isn't a good way to get interoperability or to convince authors that they can rely on the feature. Considering how hard a time Web authors have using the Vary header, I think the Key header is way over-optimistic. It seems like a feature for Google and Facebook but not something that Web authors in general could handle. Instead of referring to an undefined concept of "density independent pixels", the spec should refer to CSS px. The definition for CH-DPR and DPR should be explicit about which of physical pixels and CSS px is the divisor. The concept "the display width of the requested resource" is ill-defined. Does "display width" refer to the width of the screen or the width at which the resource will be displayed? If the former, the concept is badly named. If the latter, the concept is conceptually flawed, since the width is generally not known at the time the resource is requested and can even depend on the resource itself. The definition of the DPR response header appears to affect the concept of intrinsic size for CSS purposes, but the spec doesn't say how exactly the response header interacts with the CSS concept. The "IANA Considerations" section claims that "Accept-CH" and "DPR" are HTTP request fields even though they are response headers.
Flags: needinfo?(hsivonen)
Henri, thanks for the great feedback! (In reply to Henri Sivonen (:hsivonen) from comment #20) > The ID has two hints: CH-DPR and CH-RW. CH-DPR is bitmap-oriented. CH-RW > assumes that the HTTP request has a context where the concept of display > width is relevant. In theory, there could be more hints in the future, but > the ones being proposed now are pretty image-oriented! As the spec stands today, that is true, but only so because responsive images are a P0 problem for developers - this is a practical decision on my part to focus on this particular problem. Earlier drafts of the spec also included a "touch" hint, which was requested by many different people, but I took it out for the moment to focus the discussion. In the long(er) term, I'm hoping we'll see more hints and use cases that can be covered by CH. That said, if there are any hints in particular that you (or anyone else on the thread) thinks we should consider, I'm definitely all for it! > > A few bytes compared to kb of images, CSS, etc. Plus with the coming of > > HTTP2, it means only on the first request because subsequent requests will > > be happening in the same session. > > Unfortunately, HTTP 1.x will be around for long time, so "HTTP2 fixes the > problem being introduced here" is not a persuasive answer if the problem is > actually a problem. Also, the request headers flow in a different direction > than images, CSS, etc. HTTP/2 is not the full answer, but it's an important part of the answer. On the bytesize concerns, we are talking about adding ~20 bytes with CH-DPR, CH-RW in upstream direction, and there are no immediate bottlenecks there. From our earlier conversation, quoting Patrick McManus: ---- "The only factor that moves the needle on empty-body request transmission performance is whether or not you spill the TCP congestion window. Realistically this means anything below 4500 bytes (3 packets) takes a ~fixed amount of time and anything over that adds 1 round trip time to grow the window. Crossing the other packet boundaries is not interesting from a performance standpoint. The only 2 things that get us anywhere near 4500 bytes are cookies and on rare occasions URLs.. with normal urls and no cookies we start with a baseline request in the 450 byte range. (i.e. only 10% of the way there). Cookies sizes have a pretty wide distribution (thousands of different sizes).. its a very small slice of the universe of cookies that would move from the 3-packet bucket to the 4-packet bucket with the addition of say 50 bytes of a new header.. It's not a 0 set, but its pretty small. So I agree there is a bar here, the bytes need to have some value, but I don't want to get into a place where we argue header space is supremely expensive. Realistically there is headroom available most of the time." ---- > Since CH is now opt-in (which is better than it's not being opt-in!), you > can't use it for changing the full UI in the sense of varying the outermost > HTML document, since the request for the outermost HTML document happens > without CH whenever the requesting HTTP stack is in a state where it doesn't > have a CH opt-in cached. Yes, that's a limitation of going to an opt-in model. That said, I think it's a reasonable trade-off: it eliminates header overhead for sites that don't support CH, while still allowing sites that opt-in to optimize their subresources even on the very first load (images being the case we're discussing here, but also CSS, etc). On a second visit, once the UA caches the CH hint, the HTML doc can be optimized as well. > src-N isn't really that complicated for non-complicated designs. CH requires > to change server-side program logic instead of just changing HTML or CSS > when they want to adjust the design. "Just changing HTML or CSS" being easier is, of course, a relative statement. Even in non-complicated design cases, simply dropping a high-DPI / high-res asset on the server is as simple as it gets: let the server deal with it (convention over configuration). The infrastructure to do dynamic resizing, rotate, crops, etc., is already quite common.. plenty of open-source options, in-house implementations, and pay-for services that handle this. Also, note that for FEO and browser proxies it is much simpler to adjust the image on a per-request basis via appropriate information communicated in the headers, instead of attempting to parse and modify the HTML + modify the image. In fact, often they don't have access to HTML to begin with. Practically speaking there are only half a dozen popular servers out there that would have to implement CH, as opposed to having to convince every site to update their HTML or CSS. I can think of many sysadmins and platform/hosting providers who would be more than happy to do the work to roll out CH and enable this functionality for hundreds of thousands of sites overnight. > (In reply to Ilya Grigorik from comment #16) > If you zoom on desktop, the device pixel ratio changes without all HTTP > requests for the parts of the page getting replayed. If you change the > window size on desktop or rotate the screen on mobile, the width of the weep > or changes without all HTTP requests for the parts of the page getting > replayed. So both cases are definitely different from how things would work > with CH unless CH forces a reload upon rotate, window size change (hello > Netscape 4!) or desktop zoom. > > Upon rotate, window size change or desktop zoom, unless these imply > re-issuing HTTP requests somehow. And, if these are meant to imply > re-issuing the HTTP requests, then CH isn't actually a pure HTTP-layer > feature and the impact on the higher layers needs to be specified and > assessed (at which point we should really be putting the effort into > client-side respimg and CSS OM opt-out instead). Right, I think I'm with you now. I've tried to work through a bunch of examples in this doc: https://docs.google.com/document/d/1LMIsnoJuzf55_Wr1sJ8dpX4DHPs_P838PMCUNb5p2fI * DPR and resource-width updates may need to trigger new asset requests with CH. * Without a predefined set of breakpoints, this may require new request on every update. ** Implementing Key resolves this by allowing the server to specify the parameter range for which the returned asset should be considered valid. ** The parameter range can be based on available asset variants, custom configuration, or dynamic optimization to optimize cache hit rates or other criteria. ** Alternatively, perhaps there is also an in-between strategy here to allow the UA to make some reasonable decisions as to when request should be dispatched, instead of forcing a new request on each and every update. (To me, this is a less preferable route, but stating it here for completeness.) > Comments on the current spec... <snip> Thanks, great feedback, will merge / update in next run of the draft!
With the picture element set to ship in various browsers, is client-hints dead? Should this bug be resolved as won't fix? http://dev.opera.com/articles/native-responsive-images/
Client Hints is a complementary technology to picture. I'm still hopeful we will support it in the future.
One of the client hints benefits is to offer a solution outside of the markup. Aka you could "upgrade a Web site" without having to change the markup, because everything goes through HTTP.
(In reply to Lawrence Mandel [:lmandel] from comment #22) > With the picture element set to ship in various browsers, is client-hints > dead? I'm hoping that's the case, but the issue of having as solution for not downloading useless stylesheets remains. I think we should address that issue by adding an attribute on the <link> element for opting out of synchronous CSSOM access. > Should this bug be resolved as won't fix? Seems reasonable. At least I think we shouldn't implement client-hints before we've seen whether demand for client-hints goes away after the picture element and a way for avoiding loading stylesheets whose media query doesn't match have been out there for a good while in multiple browsers.
I strongly disagree. While <picture> is great and can help in many situations, I think it's dramatically more complex to deploy for existing content. I don't see a reason why we wouldn't want to implement Client Hints headers as well as it will help more people make more websites faster, which is good for the web. The main downside of CH that has been brought up has been concern about additional overhead when sending more headers. However having talked with the network team, they do not share this concern.
Indeed, Client-Hints is a complementary server-side solution to <picture>, and meant to integrate well with it [1]. It can be easier to deploy to handle some of the responsive images use cases in some circumstances (e.g. legacy content, 3rd party acceleration modules, CDNs). The network overhead concerns were addressed in the Client-Hints proposal by making it opt-in, so the (marginal) overhead is incurred only when the feature is used. I'd love to see Mozilla supportive of this feature. [1] https://github.com/igrigorik/http-client-hints#interaction-with-picture-element
CH was never in competition with <picture>. The goal, from the start, was to augment what <picture> offers and provide a way to let the client+server auto-negotiate the common cases... Something your local server, a CDN, or a dedicated image optimization service, could automate and deploy quickly without requiring any (or minimal) markup changes. I have a few outstanding comments on the spec that I'll try to address in the coming day or two. Stay tuned.
In my ideal world, we would use the <picture> element mostly for art direction purposes, and we would use headers (via Client-Hints for resolution/DPI, and the Accept header for things informing WebP support) for performance purposes. Of course, the picture <element> is capable of choosing the ideal image based on the conditions of the device, but that requires some complex markup - I'd rather it be automated and have servers take care of that for me :)
Updated spec: http://igrigorik.github.io/http-client-hints/ It's mostly editorial changes. That said, a few things worth noting: the hint syntax was simplified; the CH- header prefixes are gone; confirmation header has been renamed to Content-DPR; plus lots of small definition and language improvements. Also, please take a look at the extended readme that covers the various use cases and interaction with img and picture elements: https://github.com/igrigorik/http-client-hints - the "resource selection" section in particular might be of interest, since that was one of the earlier hangups with respect to extra requests (which are not a problem). Let me know if you have any feedback, comments, etc!
Does this have a Client-Hints-based solution that doesn't result in a Netscape 4-style experience: > If you zoom on desktop, the device pixel ratio changes without all > HTTP requests for the parts of the page getting replayed. If you > change the window size on desktop or rotate the screen on mobile, > the width of the [view port] changes without all HTTP requests > for the parts of the page getting replayed. So both cases are > definitely different from how things would work with CH unless > CH forces a reload upon rotate, window size change (hello > Netscape 4!) or desktop zoom. ?
CH does not affect or modify current browser behavior. That is, if you have relevant rules (MQ conditions) that are triggered based on some environment change, then a new request would be initiated. On the other hand, if such rule is not present, then the decision to trigger the request is deferred to the user agent - i.e. the browser may choose to rescale the existing asset, or it may initiate a new request. Note that the latter case is not defined by any of the specs, and was intentionally left open for interpretation (e.g. recent srcset discussion [1]). If you need hard guarantees for a different resource variant based on viewport/DPR/etc change, you should be using MQ's for "art-direction". The behavior here is the same, regardless of whether CH is used or not. [1] https://github.com/ResponsiveImagesCG/picture-element/issues/230#issuecomment-53125261
Alias: client-hints
[blink-dev] Intent to (re-)implement Client Hints: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/vOgv-TqefsA Would love to see support from Mozilla side as well! If there are any outstanding questions or concerns, let me know.
I'd like to support this. Though I still think the main problem of the spec is that it doesn't go far enough. In particular I'd like to see us sending some set of headers when loading document resources. But that can certainly be a separate spec/bug.
Jonas: yep, I think that one is worth tackling as a separate and followup issue. I've run into a lot of resistance in the past around adding new and "on by default" request headers, and hence I'd like to decouple that discussion from the rest of the spec. Also, I think once we have some hands-on experience and case studies, it'll be a much easier case to make.
I’m against this. Reasons: 1) “srcset w” syntax is the future, and it solves for all of all of the usecases discussed. We’re there already, or almost. This is a ton of conceptual overhead to slim markup very slightly. We’re talking about taking off the wire: srcset="wolf-400.jpg 400w, wolf-800.jpg 800w, wolf-1600.jpg 1600w" and that above GZIPs really nicely. 2) DPR switching alone generally isn’t crucial. It’s aesthetic. So your 1x png icon file in your navigation looks a little soft on someone’s tablet? Add a srcset attribute. Or don’t! Or use “compressive images”, and save a 2x image with severe compression. The fixes are known, and simple. I don’t buy the argument that simple 2x switching is onerous to implement on existing sites. If a brand absolutely needs resolution switching, they’re probably redesigning every three years anyway. If the developer built everything at 1x as a PSD, there will never be a magic server side button to make everything 2x-friendly. 3) Having two different files at two different resolutions with the same exact same file name is bad developer aesthetics, and also guaranteed to confuse users. Heck, it confuses me. It makes old fashioned version-control impossible. Picture got this right. 4) Server-based resizing currently fails regularly. It’s very hard to get compression exactly right for the cases that matter. If you are art-directing picture, you need a human being to evaluate on an image-by-image basis. This may evolve but I haven’t seen it happen yet. 5) It increases fingerprinting across the user base, even if an opt-out switch is provided. This is the elephant in the room. “it's a generic mechanism that can be extended to any number of use cases” Yeah, that’s the problem. If I have javascript turned off, the size of my viewport is absolutely none of the server’s business. A hard line needs to be drawn here with respect to privacy. I’m a little disturbed that there’s zero discussion of fingerprinting anywhere in this thread. This does not belong in a Mozilla product. See metabug 572650. Personally, I would like to see the energy around this dedicated to improving authoring workflows, and building apps and high quality scripts that make multi-source output a breeze. Something like ImageOptim on the Mac, with multi-res output, and a image-accurate multipane GUI, etc. Ilya, please build it and I will buy your app :)
Doesn't <picture> and the "srcset w" syntax have the same fingerprinting issue?
(In reply to Jonas Sicking (:sicking) from comment #37) > Doesn't <picture> and the "srcset w" syntax have the same fingerprinting > issue? Same question for <link rel=stylesheet media>
(In reply to Alex Bell from comment #36) > I’m against this. Reasons: > > 1) “srcset w” syntax is the future, and it solves for all of all of the > usecases discussed. That does not preclude the need for a server-based solution, which removes the requirement for modifying the markup altogether, and enables the client+server to deliver a fully automated (and more efficient) implementation. For those that want a manual override, the markup solution is always there. > 2) DPR switching alone generally isn’t crucial. It’s aesthetic. This is highly subjective. For some, it's crucial. > If the developer built everything at > 1x as a PSD, there will never be a magic server side button to make > everything 2x-friendly. Sure, but this is a completely orthogonal discussion. > 3) Having two different files at two different resolutions with the same > exact same file name is bad developer aesthetics, and also guaranteed to > confuse users. Heck, it confuses me. It makes old fashioned version-control > impossible. Picture got this right. Most mid-large apps use image services/backends to automate resizing, cropping, format negotiation, etc. In other words, they're not versioning every image variant -- those are typically generated on the fly and cached. CH is designed to empower these services to automate delivery of responsive images. > 4) Server-based resizing currently fails regularly. It’s very hard to get > compression exactly right for the cases that matter. Virtually every Google product is served by server-based image resizing + management services. This statement is simply not true. > 5) It increases fingerprinting across the user base, even if an opt-out > switch is provided. This is not true. CH does not expose anything you can't already get by executing a single line of JavaScript and/or using srcset/picture. > Personally, I would like to see the energy around this dedicated to > improving authoring workflows, and building apps and high quality scripts > that make multi-source output a breeze. That's exactly what we're doing. The optimal authoring workflow is one where the user does not have to worry about this problem at all... Just like you don't have to worry about gzipping your files and client+server do all the necessary work on your behalf.
> 1) “srcset w” syntax is the future, and it solves for all of all of the > use cases discussed. > That does not preclude the need for a server-based solution, which removes the > requirement for modifying the markup altogether, and enables the client+server to > deliver a fully automated (and more efficient) implementation. Okay, but why can't the server just modify the markup? That could be "fully automated" too. The point, which I sense you get, is that the efficiency gain after gzipping is almost nil. > Sure, but this is a completely orthogonal discussion. Well, not quite. Compressive images solves an incredible range of non-art-direction use cases. Most, I would speculate. Double the pixel count and compress heavily. Done. Lots of Googlers have already independently come to the conclusion that responsive images in general was in some way overblown. (Not saying I agree.) > Most mid-large apps use image services/backends to automate resizing, cropping, > format negotiation, etc. In other words, they're not versioning every image variant > -- those are typically generated on the fly and cached. CH is designed to empower > these services to automate delivery of responsive images. You're not answering the objection. Identically named files at different resolutions are confusing for users. This was heavily litigated for years in the RICG discussion. The hand-coders won :) Sure, there are probably cases in which they probably make sense, but we shouldn't build the platform around that assumption as a convenience to some mega-sites who want to do it that way. The point is that servers could still generate "on the fly" with a markup-based solution. The standard is enough, and it even provides a way for savvy users to inspect the range of image URLs available for an element in dev tools (which is great!). So why is the pre-versioned versus on-the-fly distinction relevant here? >Virtually every Google product is served by server-based image resizing + management services. > This statement is simply not true. It sure is true. I see crummy JPG artifacting all over the web, every day, server-generated and not-server-generated. In fact, the worst offenders actually seem to me to be server-generated. Algorithms have gotten better but there are still cases where manual adjustment is required. > 5) It increases fingerprinting across the user base, even if an opt-out > switch is provided. > This is not true. CH does not expose anything you can't already get by executing > single line of JavaScript and/or using srcset/picture. You're right about JS. I'm basically talking about JS-disabling extensions and TOR, which unfortunately seem to be all that's left for the privacy-concerned. As I understand it (and please correct me if I'm wrong) if I currently fetch a jpg from a server directly, the server (and I'm spoofing/stripping my UA, etc etc) the server has no knowledge of my viewport size. As I understand it, this proposal would change that. TOR/no-js is obviously not the majority use case but I think it's a valid one, and I think it should be valued. The reasoning for this is discussed in full detail in the meta-bug thread I linked.
(In reply to Alex Bell from comment #40) > > 1) “srcset w” syntax is the future, and it solves for all of all of the > > use cases discussed. > > > That does not preclude the need for a server-based solution, which removes the > > requirement for modifying the markup altogether, and enables the client+server to > > deliver a fully automated (and more efficient) implementation. > > Okay, but why can't the server just modify the markup? That could be "fully > automated" too. The point, which I sense you get, is that the efficiency > gain after gzipping is almost nil. Some servers can muck with both markup and images. Others can't. Client-Hints enable image handling to be completely decoupled from HTML, which makes for better, stronger, and more scalable services. > > > Sure, but this is a completely orthogonal discussion. > > Well, not quite. Compressive images solves an incredible range of > non-art-direction use cases. I can be used to resolve the "fixed width" use-case, at the price of blowing up memory consumption for browsers that do not need it, and assuming you're not interested in handling screens with resolution higher than 2x. > > > Most mid-large apps use image services/backends to automate resizing, cropping, > > format negotiation, etc. In other words, they're not versioning every image variant > > -- those are typically generated on the fly and cached. CH is designed to empower > > these services to automate delivery of responsive images. > > You're not answering the objection. Identically named files at different > resolutions are confusing for users. This was heavily litigated for years in > the RICG discussion. The hand-coders won :) That is not true. In the RICG, it was never about srcset vs. client-hints. They are complementary solutions. One fits some users, while the other fits other users. > > So why is the pre-versioned versus on-the-fly distinction relevant here? I don't understand that question. > > > 5) It increases fingerprinting across the user base, even if an opt-out > > switch is provided. > > > This is not true. CH does not expose anything you can't already get by executing > > single line of JavaScript and/or using srcset/picture. > > You're right about JS. I'm basically talking about JS-disabling extensions > and TOR, which unfortunately seem to be all that's left for the > privacy-concerned. As I understand it (and please correct me if I'm wrong) > if I currently fetch a jpg from a server directly, the server (and I'm > spoofing/stripping my UA, etc etc) the server has no knowledge of my > viewport size. As I understand it, this proposal would change that. > TOR/no-js is obviously not the majority use case but I think it's a valid > one, and I think it should be valued. The reasoning for this is discussed in > full detail in the meta-bug thread I linked. As mentioned before, <link media>, srcset and picture all expose the same info as well. You could even say that with Client-Hints, you can have an extension that strips out the opt-in headers or the CH headers going out, and maintains user privacy better than srcset et al. Personally, I don't think that your screen size is a significant/effective fingerprinting mechanism.
(In reply to Yoav Weiss from comment #41) > (In reply to Alex Bell from comment #40) > > > 1) “srcset w” syntax is the future, and it solves for all of all of the > > > use cases discussed. > > > > > That does not preclude the need for a server-based solution, which removes the > > > requirement for modifying the markup altogether, and enables the client+server to > > > deliver a fully automated (and more efficient) implementation. > > > > Okay, but why can't the server just modify the markup? That could be "fully > > automated" too. The point, which I sense you get, is that the efficiency > > gain after gzipping is almost nil. > > Some servers can muck with both markup and images. Others can't. > Client-Hints enable image handling to be completely decoupled from HTML, > which makes for better, stronger, and more scalable services. +1, and in many cases rewriting HTML is not an option to begin with. E.g. I want to use a service like resrc.it on my site: they are not in the serving path for my HTML/CSS/JS markup, nor do they need or should to be -- that's a feature. tl;dr: if you're currently happy with a markup-based solution, that's great and you should continue to use it. But that's not an argument against providing alternatives to help automate this problem. In practice (from Chrome Data Compression proxy and other sources) we know that optimizing image bytes can yield significant (40%+) byte savings for the user, and despite all of our vocal advocacy to developers to address this.. it remains an issue. DPR + RW hints provide a route towards automation which will benefit everyone: much simpler workflow for the author; clean API (no UA sniffing, etc) for service providers; fewer bytes for the user.
(In reply to Ilya Grigorik from comment #42) >+1, and in many cases rewriting HTML is not an option to begin with. E.g. I want to > use a service like resrc.it on my site: they are not in the serving path for my > HTML/CSS/JS markup, nor do they need or should to be -- that's a feature. I guess I just don’t buy the argument that image servers can’t be edited to generate suffixed filenames, or that html servers “can’t” be edited to generate “srcset w“ markup. Templates can be edited, modules written. Static ancient html can be grepped. Ilya, as you put it yourself so forcefully in your advocacy piece on this years ago ‘Get a new server!’. Obviously it’s a two step process: Getting image servers to serve suffixed filenames, and then adding one line of “srcset w” to each img’s markup. Basically your argument seems to be that this is “hard” to do, which is only somewhat true. The example of resrc.it example proves my point. Their suggested markup patterns require access to HTML (“data-src”) in order to work. In practice, sites like rescrc.it are caching different sized files at various tiers, (small/medium/large). Those tiers can and should be put into markup according to a filename suffix convention. Srcset w syntax makes this very easy to generate. In the process, it exposes something useful to savvy users. It is not markup bloat. it is a positive, standardized, user-facing feature. We should be pushing for it in all cases. (In reply to Yoav Weiss from comment #41) > As mentioned before, <link media>, srcset and picture all expose the same info as well. Broadcasting screen size and DPR in headers is a full stop different from exposing something in JS or CSS. Please refer to the metabug thread I keep linking if you don’t believe this. Mozilla undertook a deep audit to try to anonymize headers as much as possible years ago. (Of course, it turned out to be very hard to do without breaking things.) This proposal (“header-creep” in the extreme) is mud in the eye of that effort. > You could even say that with Client-Hints, you can have an extension that strips > out the opt-in headers or the CH headers going out, and maintains user privacy better > than srcset et al. Actually, it’s completely the other way around. By adding an additional entropy point, that of CH on/off, this provides another mechanism to distinguish users. If I’m one of only a handful of people on the internet using a privacy mechanism, that has the perverse effect of de-anonymizing me. Privacy techniques require large adoption bases in order to function. > Personally, I don't think that your screen size is a significant/effective fingerprinting mechanism. Privacy experts disagree. See: https://wiki.mozilla.org/Fingerprinting#Screen_resolution and Eckersley’s paper (quite dated now but still relevant) at: https://panopticlick.eff.org/browser-uniqueness.pdf esp pages 8-9. Screen size is a “global identifier”. This is where I exit. I would like to leave to leave further discussion of header-based fingerprinting to Mozillans who understand the topic better than myself.
I agree that screen size/resolution/bitdepth provides fingerprinting. However client-hints exposes no more of that information than <picture> and <link rel=stylesheet>. Even if JS is turned off. So I could definitely see value in adding a privacy feature which hides size/resolution/bitdepth from the website. Such a feature would remove the client-hints headers, but would also disable the relevant portions of <picture> and <link rel=stylesheet>.
Alex, I think we're talking past each other. I understand your point of "its achievable with markup", but that is not an argument against enabling an alternative mechanism which obviates the need for markup and enables automation of this problem. We know that there is interest for this kind of functionality from both site developers and service providers, and that's what we're trying to address. Also, note that basic version of DPR+RW *is* implementable by any ServiceWorker-enabled site, so this is coming regardless of our discussion here. In fact, the only reason we are having this discussion is that we want to deliver a better implementation of "RW" - see [1], [2]. [1] https://docs.google.com/document/d/1SnRhnR_oWQ4Rivb7InJ9a_0T2k9CnuhNcMkd9xtLrKY/edit?usp=sharing [2] https://www.igvita.com/2014/12/15/capability-reporting-with-service-worker/
(In reply to Jonas Sicking from comment #44) > I agree that screen size/resolution/bitdepth provides fingerprinting. However client-hints > exposes no more of that information than <picture> and <link rel=stylesheet>. Even if > JS is turned off. I think it would be more accurate to say that CH exposes the same information more broadly, in a new context. In that sense there are contexts in which it is definitely "new" information. > So I could definitely see value in adding a privacy feature which hides size/resolution/bitdepth > from the website. Such a feature would remove the client-hints headers, but would also disable the > relevant portions of <picture> and <link rel=stylesheet>. +1 . Alternately such a feature could preserve headers/picture/srcset behavior but standardize the reported values at a "typical" desktop resolution in a way that allows some anonymity. Would love to see this considered.
Some historical background infos around content negotiation loosely tied to the client hints proposal. (Putting it here to remember each time I dive into these topics) * Scenarios for the Delivery of Negotiated Content using HTTP Edward Hardie, 26-Mar-1998 http://ietfreport.isoc.org/idref/draft-ietf-http-negotiation-scenarios/ * Transparent Content Negotiation in HTTP K. Holtman, A. Mutz, March 1998 http://tools.ietf.org/html/rfc2295 (Basically Client Hints on Steroids) * HTTP/1.1 (3.4 Content Negotiation) R. Fielding, J. Reschke, June 2014 http://tools.ietf.org/html/rfc7231#section-3.4 * Apache 2.4 (Content Negotiation) https://httpd.apache.org/docs/2.4/content-negotiation.html
Question to Ilya with regards to the spec. * Will/Should Client Hints be tied to the type of HTTP requests? aka GET coming from a html `img` element, CSS `background-image`, etc. would send the header. but GET for other resources such as a HTML `a` would not. * What would be the interactions in between `DNT` (Do Not Track HTTP Header) with Client Hints header? * What would be the possibility for the user to override the Client Hints? Or said differently how about user intents over the client (browser) decision to mediate a predefined scenario (ex: device has small screen, browser sends CH for small screens). - Use case 1: I browse on a device with a very small screen, but I want to be able to display on a secondary screen or print on paper images with a better resolution. - Use case 2: I browse on a device with low or high bandwidth and I might want to see or not see images with higher quality.
(In reply to Karl Dubost :karlcow from comment #48) > Question to Ilya with regards to the spec. > > * Will/Should Client Hints be tied to the type of HTTP requests? > aka GET coming from a html `img` element, CSS `background-image`, etc. > would send the header. > but GET for other resources such as a HTML `a` would not. That's up to the implementer. In the context of this bug we are specifically talking about DPR and RW hints, and both strategies are valid: you could restrict it to images only; you could also send DPR and RW (set to viewport width) for all fetches, such that the server can select the best HTML/CSS/JS variant. FWIW, we do know that many sites use device databases, etc, to infer DPR and viewport width to adjust delivered markup, so sending these hints on all requests is not unreasonable. > * What would be the interactions in between `DNT` (Do Not Track HTTP Header) > with Client Hints header? Good question, any guidance? Note that using srcset/picture would "leak" same data via the requested URL; we're not exposing anything that's not already being advertised, we're just being more explicit about it. > * What would be the possibility for the user to override the Client Hints? > Or said differently how about user intents over the client (browser) > decision > to mediate a predefined scenario (ex: device has small screen, browser > sends > CH for small screens). > - Use case 1: > I browse on a device with a very small screen, > but I want to be able to display on a secondary screen > or print on paper images with a better resolution. > - Use case 2: > I browse on a device with low or high bandwidth > and I might want to see or not see images with higher > quality. Both use cases apply to srcset/picture as well.. so, whatever mechanisms are addressing those apply to CH. That said, specifically for CH, and with SW in place, the developer can intercept the request and add/remove/modify the advertised values -- e.g. override the UA default with user/application setting, etc. For more on this, see my earlier rant: https://www.igvita.com/2014/12/15/capability-reporting-with-service-worker/
(In reply to Ilya Grigorik from comment #49) > (In reply to Karl Dubost :karlcow from comment #48) > > Question to Ilya with regards to the spec. > > > > * Will/Should Client Hints be tied to the type of HTTP requests? > > aka GET coming from a html `img` element, CSS `background-image`, etc. > > would send the header. > > but GET for other resources such as a HTML `a` would not. > > That's up to the implementer. That seems bad. Differences like that will lead to content working in one browser but not another. Avoiding that is why we have web standards. I definitely think that the spec needs to define which requests should include which headers.
(In reply to Jonas Sicking (:sicking) from comment #50) > I definitely think that the spec needs to define which requests should > include which headers. The site author is free to append any hint they like to any request (e.g. my app wants to advertise "foo-preference" based on app/user preference, and/or override a UA set preference via SW), as such we can't anticipate (let alone mandate) all the various headers and when/whether they should be sent -- e.g. my site wants to send max downlink "MD" hint for video streams, but omits it for other requests. We *can* provide guidance in the spec, but I don't think we can specify (or enforce, for that matter) "MUST send" strategy. That said, I agree that it would be nice to have consistent default UA-implemented behavior.. Send DPR/RW on all requests <modulo TBD opt-in strategy>. :)
The spec doesn't need to contain language like "Requests for images must always include headers X, Y and Z, with values A, B and C". Language like "If the page calls function obj.prop.someFunc(x, y), then include header X with value Z" So "what headers to send are up to the UA, and will likely vary between different UAs" is not ok. However "what headers to send is up to the page, and the page can use [this] API to control which headers to send" is totally fine. Comment 49 made it sound like it was up to the browser to choose to send what it wants to send. That is bad. If you mean that it's up to the page, then that's great.
I botched the first paragraph there... Here's what it should have said The spec doesn't need to contain language like "Requests for images must always include headers X, Y and Z, with values A, B and C". Language like "If the page calls function obj.prop.someFunc(x, y), then include header X with value Z" is totally fine.
@Jonas: right, ok, I see the confusion. I mean to say "the page controls which hints are sent": - SW-enabled: page is in full control over which hints are sent and on which requests - Opt-in mechanism [1]: acts as a global flag to UA to send indicated hints on all requests With that, I think we're on the same page? Figuratively speaking.. ;) [1] http://igrigorik.github.io/http-client-hints/#rfc.section.2.2.1
See Intent to Ship: DPR, Width, and Viewport-Width client hints https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/vvX1vCQihDE
Chrome 46 shipped (opt-in) support for DPR, Width, Viewport-Width, and Content-DPR: https://www.chromestatus.com/feature/5504430086553600 Also, some additional context on developer use cases and implementation: https://developers.google.com/web/updates/2015/09/automating-resource-selection-with-client-hints
No longer blocks: 1211676
Whiteboard: [necko-would-take]
I'd like to see a better answer to Henri's comment 31. (In reply to Ilya Grigorik from comment #32) > CH does not affect or modify current browser behavior. That is, if you have > relevant rules (MQ conditions) that are triggered based on some environment > change, then a new request would be initiated. On the other hand, if such > rule is not present, then the decision to trigger the request is deferred to > the user agent - i.e. the browser may choose to rescale the existing asset, > or it may initiate a new request. "rescale" seems specific to images. How does one rescale a style sheet? (Then again, the spec at http://httpwg.org/http-extensions/client-hints.html#advertising-support-for-client-hints doesn't seem particularly clear on which requests the headers are set for. What constitutes a "subsequent request"?) > Note that the latter case is not defined by any of the specs, and was > intentionally left open for interpretation (e.g. recent srcset discussion > [1]). Leaving behavior up to the UA also doesn't seem very good. It seems likely that sites will depend on the behavior of one implementation and force other implementations to match.
We are working on serving responsive images using a Service worker (https://dexecure.com). The service worker routes image requests via our servers and images are optimized and served. Client Hints makes things much cleaner for us - we just give our clients the Service worker script to add in to their webpages and their site can start serving responsive images to their users. They don't need to change their markup, etc. Picture tag doesn't help us much in this case. We still have to resort to a bit of UA parsing to support non-Chrome browsers but relying on Client Hints would be a much more robust solution.
FYI, great article by folks at Cloudinary: http://cloudinary.com/blog/automatic_responsive_images_with_client_hints
platform-rel: --- → ?
Whiteboard: [necko-would-take] → [necko-would-take][platform-rel-Shopify]
platform-rel: ? → +
Thomas, let's look where this fits in the list of priorities.
Flags: needinfo?(telin)
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: -- → P5
Flags: needinfo?(telin)
Blocks: 1609304

I'd like to express my support for Firefox implementing Client Hints, in general. This feature provides Tor Browser with a mechanism for signalling its support for Tor-specific enhancements - like the ability to resolve .onion addresses. There was initial discussion [0] about providing this signal within the user-agent string, however I'm less enthusiastic about that given Bug1609304. Other browsers that provide Tor integration will benefit from this specific use case, as well.

The above discussion around fingerprinting is important, and those concerns must be taken into account when considering which hints Firefox is willing to send.

[0] https://trac.torproject.org/projects/tor/ticket/32256

Blink/Chrome has just enabled Client Hints on Feb 11, 2021
[UA-CH] Enable feature and runtime flags by default
https://chromium-review.googlesource.com/c/chromium/src/+/2525742

This is also tied to the wider discussion happening around Capping macOS user agent string. (Bug 1679929)
https://groups.google.com/a/chromium.org/g/blink-dev/c/hAI4QoX6rEo/m/qQNPThr0AAAJ

Google intends to provide the real OS version number through the Sec-CH-UA-Platform-Version

See Also: → 1679929
Webcompat Priority: --- → ?

(In reply to Karl Dubost💡 :karlcow from comment #67)

Google intends to provide the real OS version number through the Sec-CH-UA-Platform-Version

The blink-dev thread doesn't document any proper use case for exposing the operating system version. With the capping of the macOS version we're going to get into a privacy state where the OS version isn't leaked as Mac users upgrade past the capped version and Windows users upgrade to Windows 10.

I think we shouldn't foil that success without an absolutely essential use case.

One use-case outlined in the thread from Cloudinary: https://groups.google.com/a/chromium.org/g/blink-dev/c/hAI4QoX6rEo/m/Yo1ZkTHZAQAJ (not immediately applicable to Chromium, but a valid one)

Other use-cases are outlined in https://github.com/WICG/ua-client-hints#use-cases including: OS-specific styling, OS integration, OS-specific experiments and vulnerability filtering. I'd leave it to y'all to determine if those are "absolutely essential" from your perspective.

When writing this morning, I was looking for information about Apple and WebKit. There are two threads on webkit-dev mailing list:

https://lists.webkit.org/pipermail/webkit-dev/2020-May/thread.html#31195
https://lists.webkit.org/pipermail/webkit-dev/2020-November/thread.html#31571

Henri about

(In reply to Henri Sivonen (:hsivonen) from comment #68)

(In reply to Karl Dubost💡 :karlcow from comment #67)
Google intends to provide the real OS version number through the Sec-CH-UA-Platform-Version

The blink-dev thread doesn't document any proper use case for exposing the operating system version.

I see how my comment can be misread.

More exactly Rick Byers says:

LGTM2 to fix the UA string, but only after some API (Sec-CH-UA-Platform-Version or anything else) is fully available as a work-around.

I didn't say it was done in any official way. Now I think it would be hasty to use the capping as a justification for clients hints, hence the ongoing discussion.

Webcompat Priority: ? → revisit
Severity: normal → S3

We haven't seen any real-world breakage yet, so unsetting the WebCompat-priority flag for now.

Webcompat Priority: revisit → ---
See Also: → 1750143
You need to log in before you can comment on or make changes to this bug.