igrigorik / http-client-hints Goto Github PK

Add Accept-CH to response header in server side, all is good when request is run normally as Http Request, I got all needed header CH, but when I request is run as XMLHttpRequest then is nothing to get.
Why XMLHttpRequest doesn't return CH header ?

What happens when CH is on, and we have an HTML that contains two separate <img> tags, one that contains an image that's the full width of the viewport, and another that's a thumbnail of the same image? (assuming both have sizes/width, or both start to download post-layout)

In the srcset case, the browser can be smart enough to avoid the download of the thumbnail if a higher quality resource is already in cache.

Since for CH the browser side caching is Vary based, I'm not sure that the same can be done for CH, but I wonder if we can do something to avoid this sub-optimal behavior, without adding key support in the browser.

I noticed the examples in this explainer use separate headers for DPR and Width and Viewport-Width. Is that old?

Shouldn't they be using Accept-CH, with those as values?

We'd like to allow clients to specify a "requested quality" (RQ) for web content, as a way of capturing tradeoffs between content quality, size, and time to download.

For example, a client may specifically request degraded content quality as a way of reducing the number of bytes to download or improving page load speed -- for example on slow mobile or satellite networks.

My proposal is to have a small number of discrete settings for RQ, such as "low", "medium", or "high", rather than try to define a continuous spectrum of possible values.

The concept of quality is intentionally meant to be open-ended and sites are welcome to interpret different quality settings in different ways. For example, an RQ of "high" might provide full-resolution images, heavyweight JS to provide rich interaction; while an RQ of "low" might provide lower-resolution images and minimal markup and JS to reduce the page footprint.

Browsers like Chrome and Opera already provide a user setting to request degraded quality content, however this is implemented using proxies to perform content transcoding. Relaying the requested quality to the origin site can allow it to adapt its content explicitly (rather than relying on a proxy that might do bad things to the content), as well as allow SSL-based sites to offer lower-quality content when requested by the client.

Regarding the W3C bug: Feature to make elements not load their images until needed,
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17842

If was implemented and image's did not load until after CSS has been applied, then the user agent would now know the image's actual display size.

At this point, could the client hint proposal also include an element width/height to give servers a chance to respond with an appropriately sized image?

Spec states

Save-Data = 1

The boolean is a signal indicating explicit user opt-in into a reduced data usage mode on the client, and when communicated to origins allows them to deliver alternate content honoring such preference - e.g. smaller image and video resources, alternate markup, and so on.

The term reduced data usage mode on the client conveys more towards enabling the Data Saver mode on Chrome.

It doesn't convey how other browsers tries to opt-in this feature.

Ilya,
I have updated our service to support the new header names. DPR and RW.
and backwards compatible with CH- headers.

Ed

It's not clear which file one should send a PR to (or even which one one should be reading)... the html, txt, or xml, draft.md - any of them? Can you please provide some clear guidelines for contributing and which is the authoritative file? Maybe get rid of the generated versions and put them on a different branch?

A server should assume the bandwidth bottleneck is the (s)lowest of the various communications technologies in the end-to-end connection.

For example, say a browser knows it is connected to the internet solely via 802.11g, so sends a "MD: 54" header. The router knows it is connected to the WAN via ADSL2+ with a sync rate of 12224 Kbps, so appends a "MD: 12.2" trailer or modify the header to read "MD: 54, 12.2" if there's space in the packet. The ISP and other intermediaries ought not to modify the packets as they are most likely much much more capable. (This is assuming unencrypted transmission)

The receiving server should use 12 Mbps rather than 54 Mbps as the assumed maximum throughput of the client, and resolve the negotiation accordingly.

Currently RW is defined as using the "display width of the requested resource", but it's not well defined where that display width comes from.

Since the browser has no knowledge of the page's layout when it requests images, we've long concluded that the browser should use sizes info (or possibly width) for that, and fallback to the viewport dimensions when the above is not found. We also concluded that this would be the case even after the page's layout phase in order to avoid raciness.

Can we codify that in some way in the spec? Should that be a note or part of the normative definition of RW?

Given the following example:

<img srcset="wolf-480.jpg 480w, ..., wolf-1920.jpg 1920w" sizes="...">

The same wolf-1920.jpg would be selected e.g. for

• dpr=1, calculated display width=1920
• dpr=1.5, calculated display width=1280
• dpr=2, calculated display width=960
• dpr=3, calculated display width=640
• dpr=4, calculated display width=480

A cache could respond with the same cache entry for all these requests.

If the HTML is reduced to

<img src="wolf.jpg" sizes="100vw">

the same image would be selected or created for requests with client hint headers

• DPR: 1, Width: 1920
• DPR: 1.5, Width: 1280
• DPR: 2, Width: 960
• DPR: 3, Width: 640
• DPR: 4, Width: 480

The server responds with

Vary: DPR, Width

But although it's the same image, a cache would have to create separate cache entries because the DPR and Width header values differ.
If the client sent a client hint with the needed instrinsic width (e.g. Instrinsic-Width: 1920) (the client has to calculate it in the srcset-w case anyway to compare it to the w descriptors), the server would respond with

Vary: Instrinsic-Width

A cache could respond to all the requests above with the same entry.

Marshall Roch, a UI Engineer at Facebook, reported:

Facebook has been monitoring zoom levels on our desktop site for the past ~18 months. The stats have been pretty consistent the whole time, for whatever that's worth.

~5% of hits* are zoomed out one level (about 10%). This is pretty crazy to me because Facebook's font size is already fairly small. We have anecdotal evidence that this is an accident -- bug reports that ended up being caused by zooming out, where the reporter had no idea they were zoomed out.

~10% of hits are zoomed in. If people are accidentally zooming out, they're probably also accidentally zooming in. I wish we could get rid of that source of error so that we could tell whether our font size should be bigger. Either way, it seems pretty reasonable to design for the 80+% since people who want to zoom in have an easy way to do so.

Interestingly, more Windows users are zoomed in than Mac users. I would've expected the opposite since it's so easy to pinch to zoom with Apple's trackpads. If it's happening accidentally, I don't know what to make of that."

Should client hints account for this situation? Should client hints recommend submitting zoom as a hint, or factor it into the DPR? Other thoughts?

Resource Width (RW), is the display width of the requested resource in density independent pixels on the device.

a) The initial use case is to deliver width (in dips) of image assets to the server. However, same mechanism can be used to communicate the intended display width for other resources (e.g. video, or any other resource that has a "width").

b) Also, the are possible use cases for resources that are not part of the render tree (i.e. don't have a "width") - e.g. conditional delivery of stylesheets or JS. In theory, RW could report the viewport size instead.

• For (a), are there any special cases or considerations for non-img assets when delivering RW?
• For (b), is this a valid (and useful) use-case?

http://igrigorik.github.io/http-client-hints/#advertising-support-for-client-hints

When a client receives Accept-CH, it SHOULD append the Client Hint headers that match the advertised field-values. For example, based on Accept-CH example above, the client would append DPR, Width, Viewport-Width, and Downlink headers to all subsequent requests.

What does "all subsequent requests" mean in this context? Here's my guess:

"subsequent requests with this client, to the same origin as client, with destination 'subresource' " - this seems to make the most sense to me. Without the same-origin restriction, the new headers will trigger CORS preflight requests because they aren't simple. Servers such as Google Fonts don't support preflights.

You probably want a way to opt into client hints for additional origins too. Eg:

Accept-CH: DPR, Width, Viewport-Width, Downlink; add-origin 'http://example.com'

Brotli is already supported by Chrome, Firefox and MS-Edge in development. However, most websites using CDNs are un-able to take advantage of this at the moment. This is because CDNs normalise the accept-encoding header before sending it to the origin. I have tested Cloudflare and Cloudfront and both of them normalise the accept-encoding header to just "gzip".

It would be cool if the brotli support could be advertised as a Client-Hint to the server and advertising this header would of course be an opt-in via the Accept-CH meta tag.

Some functionality only makes sense if the user has JavaScript enabled.

And even sites that are usually rendered on the client side may want to serve a server-side rendered response if it notices the client doesn't have JavaScript.

Hence a boolean JS client hint would be quite valuable.

(My concrete use case: Facebook BigPipe-style rendering: https://www.drupal.org/project/big_pipe.)

Hey Ilya,

So, I'm very excited about Client Hints, and am glad to see you're pushing it towards implementation. I'm also wary of it for a couple of reasons.

My main concerns are that, at least in my experience and in what I've observed in "responsive" asset delivery lately, device dimensions are rarely the most important factor when determining the CSS and JS that is applicable at load time. I'm glad that this information is included in Client Hints, but it seems less important than a few other factors. These are:

• Screen pixel density (which I'm very glad to see is included already in CH)
• Viewport dimensions (often different from device dimensions, particularly on larger screen devices)
• Default Font size (based on user preference), as this drives the active em-based media query breakpoint and layout a user receives.

I understand that client-side deliverables can affect the reported viewport size, and that may be the reason you cited their removal from client hints. That said, the information that an author needs to know up-front may not need dynamically-calculated viewport dimensions to be useful anyway.

If client hints sent the pixel-based dimensions of the viewport at the same scale as the device dimensions (so, iPhone would be something like 320px by 420px height, or the opposite if it was in landscape orientation), that would be very helpful on its own. In addition, if client hints sent the default font-size of the browser (16px or otherwise), then that value could be used to calculate an em-based viewport dimension, which is what authors would need when deciding which stylesheets to serve up-front in a blocking manner, and which stylesheets are inapplicable at load and could safely be loaded at a later time, perhaps at the bottom of the document or something.

Also, it'd be ideal if Client Hint data were fresh per request, as device conditions can change regularly with orientation changes, preferences, font-size shifts, zoom, etc.

It'd be great to hear about your thoughts about the issues above. Thanks!

Scott Jehl

Specifying CH-DPR and CH-RW headers for image requests (and Vary headers for image responses) is one thing. What is the recommended behaviour in terms of headers for requesting/responding the markup resource referencing images when the simplified markup syntax is used, e.g.

<img alt="A rad wolf." src="pic.jpg">

instead of

<picture>
  <source srcset="pic1x.jpg 1x, pic2x.jpg 2x, pic4x.jpg 4x">
  <img alt="A rad wolf." src="pic1x.jpg">
</picture>

in order to facilitate caching? Send CH-DPR in the request and DPR: ... with Vary: CH-DPR in the response?
What about the markup request/response for the use cases in examples 4 and 5? Does the client have to send both CH-DPR and CH-RW? If so, what is the recommended value for CH-RW then?

Maybe you can clarify this in the spec.

It seems that the status section does miss few essential players: Safari / Apple and Chrome / Google.

I would like to see some information regarding them and maybe even some hints regarding what we can do to persuade them to adopt this.

I found this "project" only now but I was wondering myself why nobody considered using this approach which seems much better than those the do require changing the HTML and CSS code in order to provide support for HiDPI.

One issue I thought of in regards to CH-RW is the fact that there could be so many different possible image size variations, and that could end up being a big problem on the caching side of things (assuming the transformed images are behind a CDN). Having to transform images to hundreds (potentially even thousands) of different sizes could end up causing more harm then good depending on your cache hit ratio, bucket sizes, and cache expiration time.

Has there been any thought into being able to define buckets of widths instead of sending exact widths in the CH headers?

Rather than defining Yet Another Syntax for header field values, how about:
http://tools.ietf.org/html/draft-reschke-http-jfv-00

http://igrigorik.github.io/http-client-hints/
2.2.2 Interaction with Caches
uses the Key header modifier r. However http://tools.ietf.org/html/draft-fielding-http-key-02 does not define this modifier. Is there a more recent version of the draft to be listed in '11. Normative References'?

Current spec language leaves a lot of room for the UA to decide what it does with "DPR" indications from the server side.
Specifically:

• It doesn't indicate that the UA should deduce intrinsic size using the DPR value (only that it may)
• It doesn't define precedence of client-side and server-side DPR indications, so if they don't have the same value, the UA can decide which one wins.

I'm afraid this may lead to compatibility issues in the way the images are displayed, when image dimensions are not specified.

Reporting of width/height values is problematic for devices that can change orientation, so individual values are not reliable anyway.

Actual viewport size cannot be reported, so these values cannot be used for precise breakpoint selection on desktop (windowed) systems anyway.

So how about avoiding it all by reporting diagonal device size? It's the same regardless of device orientation and still pretty good for getting idea wether device is a handheld/tablet/desktop/tv.

source-size values in sizes attribute values in examples 4 and 5 are given in %. According to the current picture spec (13 May 2014), source-size-value must be length and so cannot be percentage.

About a year ago, I opened issue #27, which was closed. Now that there are client hints in Chrome 46, I still have the same question. The examples in section '<picture> element' seem to make the assumption that longer markup with srcset can be reduced server-side to shorter markup, e.g.

<!-- viewport-based selection -->
<img src="wolf-400.jpg" sizes="100vw" alt="The rad wolf"
     srcset="wolf-400.jpg 400w, wolf-800.jpg 800w, wolf-1600.jpg 1600w">

<!-- equivalent functionality with DPR and Width hints -->
<img src="wolf.jpg" sizes="100vw" alt="The rad wolf">

But currently, I cannot expect every browser to send client hints. So I have to decide (per request?) when to send the longer or the shorter version in the response to a navigational request. So I need some information in the navigational request as well.
Currently, Chrome 46 does not send client hints in a navigational request. If it did send e.g. DPR, I would add

Vary: DPR

to the response. But that would result in too many cache entries for the same URI in intermediary caches (one version for each DPR header value). One version for present DPR header (shorter markup) and another for missing DPR header (longer markup) would be sufficient.
So what do you think is a good way to handle this?

Conceptually, anything we add as a client-hint could have been added to the User-Agent instead. The reasons we don't do so are primarily:

1. The User-Agent field is a mess and its structure is not well standardized
2. We want to be able to Vary based on a CH field

We're (hopefully) addressing (1) through this very definition exercise.
However, by putting all hints into one header, we're setting ourselves up for a repeat of (2). Once we add more client hints, varying on the CH header would not be very useful.

If we get support for Key at some point, this may be a lesser issue, but for now we don't have a clear line of sight to get it.

What if we added a separate header for each client-hint instead, using a standard format? For instance:

GET /a.jpg HTTP/1.1
CH-DPR: 2
CH-FontSize: 3
...

This will allow us to use Vary on one or more of these fields for very little overhead, which will get even smaller with HTTP/2.

@igrigorik -

I'm trying to wrap my head around this proposal. I think I'm starting to get it after the conversation in issue #3. That said, a use case would be helpful as well. This is how I'm picturing client hints could be used... I'm picking a silly example so feel free to tear it down. I wouldn't actually do this ( I'd serve different mark-up based on CH that had different image sources that had normal cache headers ) but I could see CH being bent in this way.

My responsive site sits behind a CDN. I want to make sure my hero image on my home page is properly sized from a file size standpoint based on my site's breakpoints:

• 320px wide image for smaller viewports (less than 480px),
• 640px wide image for medium viewports (greater than 480px and less than 768px)
• 960px wide image for larger viewports (greater than 768px)

Let's assume we have an img tag that references a server-side script instead of an actual resource so that the script can take direct advantage of the headers. The script functions as so:

1. uses CH's dw attribute to determine the appropriate image to serve
2. return the image with the extra headers Vary: CH; Key: CH;pr=dw[X:X2] where X and X2 are based on my breakpoints. (e.g. I'd only have three possible combos in cache at the CDN pr=dw[:480], pr=dw[481:768], pr=dw[769:]).

So then the CDN would never have to get the file again until other headers expired.

I presume that's an optimal use case. What I'm having trouble understanding is a similar use case that involves a CDN where the key isn't used. Is the CDN supposed to simply use the requesting UAs CH info as a key and then deliver appropriate material? That seems like Vary: CH suffers from the exact same issue as Vary: User-Agent. According to Google Analytics, our most popular site has recorded 1,585 different screen resolutions. According to GA help that's of the monitor, not browser window (which I think is what your spec is actually using). How much variation is too much variation from a CDN perspective?

It seems like the proposal should require the use of a server-supplied Key if it wants to be CDN-friendly. I personally don't have a problem with that but I'm curious if I'm reading the spec correctly.

Count me as someone who is excited about this proposal. Assuming I have the use case correct, I could use this today to replace the vast bulk of what we use Detector for on our home page. This is always going to be a targeted, scalpel solution.

Thanks for taking the time to review this.

If user embeds an image with <img src=""> without explicit size and uses CH to send "Retina" image, the image won't be in higher-resolution, it will remain lower-resolution and be displayed at twice the size.

Should there be a feature that allows the server to indicate that it has used CH and sent higher-density image, so that the browser knows correct size of the image?

Problem

It is difficult to tell if a given browser agent is using light or dark mode UI, and respond to that, without waiting for JavaScript to boot up, or applying a media query in CSS. These existing techniques cover most cases but don't cover all of them. In particular:

• Switching the favicon for the page
• Applying different images for dark or light mode (block images - background images would be covered by media queries)
• Choosing App Manifest values based on dark or light mode (in particular, theme colors/swatches)

Rationale

Switching the favicon is a particularly salient example. With the transition to dark/light mode support, many companies - large and small - are now caught with dark icons that don't work well with dark-mode UIs. Below, an example of "getting it right" vs. not:

If you squint real hard, you can see the Github icon, but Dark Mode doesn't make it easy. Google's approach - a field of white - works in all modes, but also pops when it doesn't need to:

Favicons are not settable via CSS, but they can, of course, be changed with JavaScript. The problems with this approach are likely the cause of both issues above.

Google, and companies like it, want a consistent favicon experience so that users can easily identify their properties. However, to account for the above contrast issues in dark/light mode, Google would be forced to adopt JavaScript code on every single property and page in order to appropriately serve or change the favicon. This is sub-optimal for a number of reasons:

1. Adding JS to change the favicon incurs a runtime code increase, across all pages and properties, regardless of whether the user ever changes their theme, and for the marginal benefit of a favicon that lives in harmony with the world around it. This is already a tradeoff most developers quite sensibly wouldn't make.

2. Even worse, this approach is unable to be proactive, because the browser won't wait for JS to load a favicon declared by markup, or one served at the root of the site. In fact, waiting will yield an error by default on some page-loads (at least in Chrome - a 404 for /favicon.ico). At best, there are workarounds (serving a transparent favicon and then substituting with JS), but no optimal way to simply serve the right icon the first time.

3. As usual, the exclusive advantage of JavaScript here is event-based programming. However, what percentage of users change dark/light mode while on a given web page, versus landing on that web page with dark mode and later leaving, having not changed it? Many fewer, of course, which mitigates this advantage almost entirely.¹

Potential Solution: Client Hints

Meanwhile, there is a new feature in HTTP land that seems well-suited to help solve this problem: Client Hints! Let's suppose there was a new Theme hint.

Now, my examples might look like this:

Browser:

GET https://www.google.com/

Google:

200 OK
Accept-CH: Theme
Content-Type: text/html

... later ...
<link rel="shortcut icon" href="/favicon.ico" />

Browser:

GET https://www.google.com/favicon.ico
Theme: Dark

Google: *serves an epic icon for dark mode*

This approach could, of course, be extended to stylesheets and scripts which can now be aware of the theme and serve other resources appropriately. Images aside from the favicon could choose to invert transparency or perform other tricks, and stylesheets/scripts have a chance to adapt as well.

This CH-based approach accomplishes a solution to the favicon problem with a much less invasive approach: (1) the document endpoint must serve Accept-CH (already true), and (2) the assets that change must honor the new hint. Although this change isn't universally trivial, it only touches assets that change, rather than every page on every property, which is a crucial win.

Privacy Concerns

Technologies like Client Hints present an inherent risk of information leakage (i.e. HTTP fingerprinting and related mitigations). Of course, balancing these risks with legitimate performance/experience concerns is always a challenge.

However, Dark mode/Light mode likely doesn't present much of a risky change from a privacy standpoint, for a number of reasons:

1. Dark/light mode is a function supported across most modern operating system UIs (macOS Mojave+², Windows 10+³, GNOME 3, iOS/iPad OS 13+⁴, Android 10 (API level 29+)⁵).

2. There are multiple ways to end up with Dark mode¹ (i.e. it is not only a consequence of a static setting chosen by the user). This eliminates any meaning of categorical value for a Dark mode hint from a given client, because for an increasing number of browsing agents, it may simply be the result of a temporal condition (i.e. the time-of-day where the user is).

3. Many users opt to use dark mode full-time. I do not have access to statistics describing how many opt into this feature, but the Chrome team might (( ͡~ ͜ʖ ͡°)). What I can tell from outside Google is, Dark mode has been supported directly since Chrome 73, which was released in February 2019 (over a year ago, as of this writing). Chrome 73+ (again, as of this writing), represents about 63.21%⁶ of the entire browser-agent footprint internet.

4. Aside from Chrome, Safari 13+ brings in an additional 12.95% of the internet, bringing the total to 76.16% of measured browsers (from Can I use) that could feasibly have dark-mode enabled via a static setting. I bring up this point to illustrate the lack of fingerprint value in a dark mode Client Hint, even when combined with other CH values like RTT, in terms of identifying the approximate location of the user emitting the hints. That is to say, it is perhaps no less risky than the RTT or Theme hint, sent on their own.

5. The Client Hints Delegation proposal on W3C's Feature Policy spec might further mitigate these concerns in a substantial way.

I know this is just a rough start estimating the privacy implications, but I anticipate this may be a concern, so I wanted to surface some thinking on it to get the ball rolling.

Prior Art

I could not locate an existing issue or proposal relating to dark/light mode Client Hints, but of course, I could have missed something.

Citations

¹: macOS now supports dynamically switching from dark/light and back based on the current time-of-day, so this may happen more often now.
²: "How to use Dark Mode on your Mac"
³: "Windows 10 dark mode is here. Turn it on now"
⁴: "iOS Human Interface Guidelines: Dark Mode"
⁵: "Android Developers: Dark Mode"
⁶: "Can I use: Browser Table"

Can you please put this on gh-pages? It sucks having to check it out just to read it.

During the webkit-dev discussion, a proposal was raised to split the "resource-width that falls back to viewport-width" hint to two distinct hints that would indicate "Viewport Width" and "Resource width" separately.

• Is that something that would be worth while?
• When the browser has the resource width, should it send both or only one?
• What should the Accept-CH opt-in be?

In section 2.3 there is an example "Client-Hints-Support: dv, dh, dpr"

It probably should be "Client-Hints-Support: dw, dh, dpr"

The meaning of the communicated value is deferred to the server

That means that Firefox's "low" may mean something different than Chrome's "low" (or Firefox may not have "low", but "LQ", or "highly compressed"), which will force servers to keep track of a map of RQ values to their actual semantics.

Of course the server should control what "low" means in terms of its compression parameters, but it should know that "low" means "low".

In other words, I think we should figure out a small set of keywords and stick with them.

Does DPR and RW hints account for browser zoom, or is it a fixed device+screen based value?

Windows 8 laptops support touch, but that doesn't automatically mean that user is using touchscreen.

I recall Chrome team had a problem with sites detecting touch support, switching to touch events, and effectively disabling mouse for laptop users who happened to have an (unused) touch screen in their laptop.

Related rant: http://www.stucox.com/blog/you-cant-detect-a-touchscreen/

Hello Ilya,

I am really happy you are approaching this topic so constructively.

While proposal process and implementation is undertaken, I was wondering if one could use the device detection engine of various CDN vendors (Akamai, Edgecast, CloudFront, .. ) or your own caching proxy to create some sort of serve-side polyfill so we can start implementing this using the new HTTP headers now? So the idea is to have a simple UA-string to Client Hints "function" in the CDN layer.

Example

Assuming a iPhone 6 with Safari Mobile is accessing a webpage URL (let's say HTML for simplicity) and does not send client hints itself. Would it be meaningful to let the device detection engine in the CDN translate the UA string to client hint headers, if no client hints are present. Of course I am mostly concerned about mobile devices, given they are the weakest clients.

Original request

Mozilla/5.0 (iPhone; CPU iPhone OS 7_0 like Mac OS X; en-us) AppleWebKit/537.51.1 (KHTML, like Gecko) Version/7.0 Mobile/11A465 Safari/9537.53

could result for example in adding the following client hint headers to the request.

Modified request

DPR: 2.0
Width: 160
Viewport-Width: 320

Then, the webserver could deliver optimized HTML to the client, as described in the proposal to optimize the critical render path. Probably not perfect, but surely better than speedtest detection and other measures that require javascript execution and roundtrips?

Of course, the CDN must be configured to cache this URL + header combination from now on to preserve cache efficiency.

Is this totally a bad idea or do you have any thoughts on this?

PS: I would deliberately exclude Downlink, I guess that is not really possible without Javascript being executed on the client?

Some thoughts about client hints, CMS servers and URLs of image variants:

A web/cms server might want to serve individual size variants of an image under individual and unique URLs. For example to still allow their direct retrieval via "srcset" attribute of an img/picture tag, and because it might just be regarded good practice to let each individual resource have an unique URL.

If an image request is processed by a CMS server and the server chooses an image based on the given client hints it therefor might not want to directly return the image data. It may choose to redirect to the unique URL of the chosen image variant instead.

In that case however it should be assured that the "DPR" response header, given on the response that does the redirection, is still processed by the user agent normally, so it knows how to use the image regarding device pixel ratio, even though it needs to do a redirect to fetch the image data.

Additionally it may need to refrain from sending client hints again on the redirected requests as the choice has already been made.

Granted, I am not entirely sure if I see things correctly here. But as we develop a Web CMS and are currently experimenting with serverside support for client hints the question was raised if we could just redirect to the chosen image and everything would still work as intended.

I think the CH- prefix should be dropped from the header names here.

If the draft was describing an overall framework for Client Hints whereby a server could do something interesting with headers beginning with "CH-" when it didn't otherwise recognise them, it would be worthwhile.

However, it's not; really, this draft is just defining a couple of new request headers. "CH-" just wastes three bytes (yes, it's still important), and leads to a sort of cargo-cult "my header needs a CH- prefix" starting to show up in other efforts.

The RW hint is defined as an int, but it's not well defined how the rounding of that value (when using sizes based value) should be rounded.
I don't think it really matters if we define it as round-down/up/closest, as long as it's well defined and browsers are consistent.

@igrigorik During a discussion with a big Web site, they had this context.

1. They send different image resolutions to different devices.
2. They need to know it before the image call (so at the initial HTML request)

window.devicePixelRatio is not working and client Hints for Image HTTP Request is too late. I guess they built the URI in the template on the server side at the initial request.

Do you think client hints would be able to address this use case?

From @sleevi on blink-dev:

It doesn't seem like there's anything substantive in the spec about the privacy implications, other than two sentences under Security Considerations. It seems at least worth calling out explicitly, even though https://www.chromium.org/Home/chromium-security/client-identification-mechanisms and http://www.w3.org/wiki/Fingerprinting exist. For example, https://w3ctag.github.io/security-questionnaire/ has a good set of questions that should ideally be documented in the spec

The draft needs to be consistent and clear -- can CH-* be set by any client (including proxies), or just by UAs?

While discussing the feature on webkit-dev concerns were raised with regard to the feature's defined short header names, and the fact that they may be too obscure.

I also heard similar concerns from other people hearing about Client Hints for the first time.

Maybe we should consider longer names?
e.g. DevicePixelRatio, ResourceWidth, MaximumDownlink, ResourceQuality

@igrigorik and @mnot - WDYT?

I am wondering how a DPR-based selection/scaling process would look like server-side, given the following example:

<!-- alternative and equivalent syntax -->
<img src="pic1x.jpg" srcset="pic2x.jpg 2x, pic4x.jpg 4x" alt="A rad wolf.">

<!-- equivalent functionality with DPR hint -->
<img alt="A rad wolf." src="pic.jpg">

Selection: If pic.jpg is a key that is mapped to pic1x.jpg 1x, pic2x.jpg 2x, pic4x.jpg 4x on the server, then with a request containing a DPR header the server-side process can select the appropriate URL from the variants given by pic1x.jpg 1x, pic2x.jpg 2x, pic4x.jpg 4x. Fine.

Scaling: Unlike the width, which is a property of the image itself, the DPR is sort of a scaling factor and therefore a property of the image's intended use. So, in my opinion, if pic.jpg acts as a placeholder for some source image URL, the intended x for this source image must also be known, in order to calculate the width of the transformed image suitable for the intended scaling factor given by the DPR in the request.
E.g.: The resource width of the source image referenced by pic.jpg is 1600 pixels. A request for pic.jpg contains the client-hint DPR: 3 (and no Width header! That would make it a different use case). What width should a server-side scaling process scale the source image to? This can only be answered if the intended x for the source image is known. Let's say this intended x is 4. So the process would scale the 1600 pixels wide image to 3 (from DPR) / 4 (intended x of the source) * 1600 pixels = 1200 pixels.

Any thoughts?

Building off of an idea from Guy Podjarny (https://twitter.com/guypod/status/329436405447147520) it'd be great to be able to opt-in for CH requests by meta tags.

Developers could place a meta tag within <head> and before any resources, such as:

<html>
<head>
    <meta name="X-CH-Request" content="dw,dpr,t">
    <link href="styles.css" rel="stylesheet" />
</head>
<body>
    <img src="image.jpg">
    <script src="scripts.js"></script>
</body>

In the above, styles.css, scripts.js, and image.jpg would all receive the CH request header. Let's say the client has a device width of 384, device pixel ratio of 2, and supports touch, then this header would be included in each of their requests:

CH: dw=384, dpr=2.0, t

The meta tag would inform the user-agent which header fields it needs to calculate and send with the request. For example, in the meta tag I didn't include the dh field, but did include dw dpr and t. On a standard desktop, even though the meta tag included t, a user-agent which does not support "touch" will know not to send the t field. If the content attribute is missing from the meta tag, or is empty, then the user-agent should send all of the CH fields.

Additionally, I would argue that for step 1 in implementing client hints, that the initial page request (the html page that would contain the meta tag) does not need to receive the CH request header. While there are cases of webpages that include html, javascript and css all in one response, I believe the percentage of these types of implementations are minimal compared to the traditional design (html with external resources using <link href> and <script src>).

One of the biggest reasons NOT to implement client hints is because of the extra bytes we're adding to every request. With this method it allows client hints to be an opt-in feature for resources, but most importantly gives developers valuable information which can be used to reduce sizes of responses, and/or make decisions on the best resource to respond with.

"If the hint name is absent in the last message containing the client hint header field, it is considered false."

How does this work, now that Client Hints is split up into separate headers? It sounds like this effectively means that Boolean hints have to be sent on every request if they're true, otherwise they're false.

If that's the case, it'd probably be better to just come out and say so.

Mobile browsers now all have a "Request desktop site" feature, either on per page basis (like Safari or Chrome) or globally across the browser (like Opera), which changes the User Agent to a desktop one.
When enabled, the user intent is to expect a desktop or tablet size layout when available, as opposed to a responsive device-with.

The desktop (non responsive) default viewport being 980px in webkit or 1024px in IE Mobile.

Should client hints indicate a Width and Viewport-Width of that size instead of the responsive viewport?

I am not arguing either way, though leaning towards exposing that default viewport.

Just want to bring the use case ahead of time, for the appropriate approach to take for mobile browsers in that feature's context. And make sure that all browsers follow the same standard down the road, and not inventing their own different ones.

AFAIK dpr name is not used anywhere else in the platform. CSS equivalent is called dppx, so I suggest using that name.

CH: dppx=2

(or if you really want to save bytes on wire, then you could use naming consistent with srcset and image-set(): CH: 2x ;)

Alternatively you might try to convince CSS WG to use dpr instead. It's just that having two names for essentially the same thing is messy.

As a bonus you could refer to CSS3-values spec and avoid re-defining resolution in CH spec.

In README.md the link 'advertise the Key caching header' in section 'Resource selection' points to
http://igrigorik.github.io/http-client-hints/#rfc.section.2.3.2
which should probably be
http://igrigorik.github.io/http-client-hints/#rfc.section.2.2.2 ('Interaction with Caches')