Intent to Ship: DPR, Width, and Viewport-Width client hints

499 views
Skip to first unread message

Yoav Weiss

unread,
Jun 19, 2015, 11:08:36 AM6/19/15
to blink-dev
Contact emails

Spec

Summary
DPR, Width, and Viewport-Width hints enable proactive content negotiation between client and server, enabling automated delivery of optimized assets - e.g. auto-negotiating image DPR resolution, image size, and other optimized assets based on signals such as client's viewport width. For more details, see [1], [2].

Motivation
Images account for the bulk of transferred bytes [3] and provided hints enable automated negotiation and delivery of optimized asset variant based on DPR, display width of the resource (when it is known at request time), and client's viewport width. In some scenrios, markup-based responsive images solutions are not sufficient: the requirement to modify and update all existing pages may be extremely expensive for legacy web sites, and some developers prefer to keep image optimization outside of markup and handle it in lower layers via content-negotiation. For more details, see [1], [2].

Compatibility Risk
Low. Provided hints are opt-in [4] and delivered on best-effort basis; there is no additional overhead for sites that don't choose to leverage these hints.

Signals from other browser vendors
Firefox: Mostly positive signals.
Safari: Mixed signals.

Ongoing technical constraints
Shipping these features is currently blocked on crbug.com/434477 since it would result in wrong values being sent on Android.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes.

OWP launch tracking bug?

Link to entry on the feature dashboard

Requesting approval to ship?
Yes.

Yoav Weiss

unread,
Jun 19, 2015, 4:00:48 PM6/19/15
to blink-dev, net-dev
+net-dev

Ryan Sleevi

unread,
Jun 19, 2015, 5:53:48 PM6/19/15
to Yoav Weiss, blink-dev, net-dev, Ilya Grigorik


On Fri, Jun 19, 2015 at 1:00 PM, Yoav Weiss <yo...@yoav.ws> wrote:

It doesn't seem like there's anything substantive in the spec about the privacy implications, other than two sentences under Security Considerations.


For example, https://w3ctag.github.io/security-questionnaire/ has a good set of questions that should ideally be documented in the spec ;)

I do think that both Downlink and Quality have some real issues, so the intent is that you'll send separate intents for those, if at all, right?

There's also venue questions - This is presented as an Informational document, rather than as a [potential] Standards Track document. It follows the IETF's RFC form, but suggests it belongs in the Network Working Group, rather than the HTTP working group. Why? What's the reaction from non-browser vendors to this extension of HTTP semantics?

What about the implications for forward load balancers or caching proxies? We've seen other features (such as SDCH) interact quite negatively with these. Should this be limited to Secure contexts, not because of the security considerations (although there's arguably ambient privacy arguments for this based on the nature of how this exposes additional passive information leakage), but because of the implementation issues?


Summary
DPR, Width, and Viewport-Width hints enable proactive content negotiation between client and server, enabling automated delivery of optimized assets - e.g. auto-negotiating image DPR resolution, image size, and other optimized assets based on signals such as client's viewport width. For more details, see [1], [2].

Motivation
Images account for the bulk of transferred bytes [3] and provided hints enable automated negotiation and delivery of optimized asset variant based on DPR, display width of the resource (when it is known at request time), and client's viewport width. In some scenrios, markup-based responsive images solutions are not sufficient: the requirement to modify and update all existing pages may be extremely expensive for legacy web sites, and some developers prefer to keep image optimization outside of markup and handle it in lower layers via content-negotiation. For more details, see [1], [2].

Compatibility Risk
Low. Provided hints are opt-in [4] and delivered on best-effort basis; there is no additional overhead for sites that don't choose to leverage these hints.

This isn't, strictly speaking, true, is it? There is overhead in the Request bodies, even if minor.

Header naming seems to have been raised by multiple vendors. I'd be curious to see what degree of review this has gotten from the wider HTTP community (aka the HTTP WG, where such a document will inevitably be proposed). I'm very much afraid that the current header names would ossify nearly immediately, and we'd end up being unable to address these.

There's also risk with the fact that there's bad interactions unless Vary is employed, and that this adds real risk to the HTTP caching layer, right? That is, imagine we go down this route and implement, and six months later, we decide it was a failed experiment or that there are insurmountable design issues that cause us to remove support. What are the implications to our users' caches when we do this? What steps can we proactively take to mitigate those implications while still allowing the ongoing experimentation and information gathering?
 
Signals from other browser vendors
Firefox: Mostly positive signals.

I'm curious how that was quantified. I read through the bug and saw a number of concerns (some of which, it turns out, I've ended up raising here - like the privacy implications)
 
Safari: Mixed signals.

Ongoing technical constraints
Shipping these features is currently blocked on crbug.com/434477 since it would result in wrong values being sent on Android.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes.

OWP launch tracking bug?

Link to entry on the feature dashboard

Requesting approval to ship?
Yes.


--
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.
To post to this group, send email to net...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CACj%3DBEi8S%3DC_HTigNyKNCLZuvy1yN5yLgqv_P72eAphdtYqzBA%40mail.gmail.com.

Ilya Grigorik

unread,
Jun 19, 2015, 7:23:37 PM6/19/15
to Ryan Sleevi, Yoav Weiss, blink-dev, net-dev
On Fri, Jun 19, 2015 at 2:53 PM, Ryan Sleevi <rsl...@chromium.org> wrote:
On Fri, Jun 19, 2015 at 1:00 PM, Yoav Weiss <yo...@yoav.ws> wrote:

It doesn't seem like there's anything substantive in the spec about the privacy implications, other than two sentences under Security Considerations.


For example, https://w3ctag.github.io/security-questionnaire/ has a good set of questions that should ideally be documented in the spec ;)

 
I do think that both Downlink and Quality have some real issues, so the intent is that you'll send separate intents for those, if at all, right?

Correct, those are independent. 
 
There's also venue questions - This is presented as an Informational document, rather than as a [potential] Standards Track document. It follows the IETF's RFC form, but suggests it belongs in the Network Working Group, rather than the HTTP working group. Why? What's the reaction from non-browser vendors to this extension of HTTP semantics?

- netwg: tooling error on this end, willfix. 
- status: CH is in the queue for the HTTP working group [1] 
- reaction and feedback: see "interest from" section in [2]; positive from various CDN/proxy providers.. some have already implemented it.

 
What about the implications for forward load balancers or caching proxies? We've seen other features (such as SDCH) interact quite negatively with these. Should this be limited to Secure contexts, not because of the security considerations (although there's arguably ambient privacy arguments for this based on the nature of how this exposes additional passive information leakage), but because of the implementation issues?

I don't believe so. For caching we rely on Vary, which is already widely used (Accept+Vary) to deliver WebP by many sites (e.g. PageSpeed uses Accept negotiation + Vary to deliver WebP), and I'm not aware of any issues there. 
 
Compatibility Risk
Low. Provided hints are opt-in [4] and delivered on best-effort basis; there is no additional overhead for sites that don't choose to leverage these hints.

This isn't, strictly speaking, true, is it? There is overhead in the Request bodies, even if minor.

As of today we don't send hints on the first navigation request. Instead, we wait for the server to respond with an Accept-CH header or equivalent <meta http-equiv> and then append those hints to all subsequent subresource requests. As a result, there is no overhead for sites that don't opt-in. 
  
Header naming seems to have been raised by multiple vendors. I'd be curious to see what degree of review this has gotten from the wider HTTP community (aka the HTTP WG, where such a document will inevitably be proposed). I'm very much afraid that the current header names would ossify nearly immediately, and we'd end up being unable to address these.

FWIW, we've done a few loops around this track already, with feedback from CDN's, browser vendors, and community at large - single header, multiple headers with short names, multiple headers with longer names, etc. I don't think we can make everyone 100% happy, but I do think we've arrived at a reasonable middle ground: https://github.com/igrigorik/http-client-hints/issues/40. Also, note that these are opt-in, so we're not imposing overhead on sites that don't leverage this functionality.
 
There's also risk with the fact that there's bad interactions unless Vary is employed, and that this adds real risk to the HTTP caching layer, right? That is, imagine we go down this route and implement, and six months later, we decide it was a failed experiment or that there are insurmountable design issues that cause us to remove support. What are the implications to our users' caches when we do this? What steps can we proactively take to mitigate those implications while still allowing the ongoing experimentation and information gathering?

As I noted above, we're not exercising any new paths that are not already in use by WebP. Throughout the rollout of that I've been in touch with various proxy + server developers, CDNs, and so on. I'm not aware of any issues. 

In fact, the only "issue" that came up is that some proxies treat any Vary that's not "Accept-Encoding" as non-cacheable... But that doesn't break anything functional, it just decreases their cache hit rate until they fix this behavior. Further Vary is being used quite actively out in the wild, see [3] for examples of Vary + Referrer, Cookie, etc.


ig

Yoav Weiss

unread,
Jun 29, 2015, 8:53:51 AM6/29/15
to Ilya Grigorik, Ryan Sleevi, blink-dev, net-dev
API owners, what say ye? Any open issues/questions?

--
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.
To post to this group, send email to net...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CADXXVKrwoOffGFNs5WwTFUWA%2BvEv3tvgEJo9d6T7B-epjYObkQ%40mail.gmail.com.

Philip Jägenstedt

unread,
Jun 29, 2015, 9:31:09 AM6/29/15
to Yoav Weiss, Ilya Grigorik, Ryan Sleevi, blink-dev, net-dev
This is not my area of expertise, but I tried to follow the webkit-dev discussion:

The final message from Maciej is still largely negative, in my reading. Is implementation proceeding in WebKit and what do you think the chances of getting this shipped in WebKit are? (For those not following links, Yoav is driving the feature in WebKit too.)

In that thread your said "That's up for the browser" and "it's skimpy on browser related details." Can't the spec just define everything so that we can get interoperable implementations? If the IETF doesn't allow you to for process reasons, perhaps another venue or a companion spec would be an option?

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

Yoav Weiss

unread,
Jun 29, 2015, 11:17:52 AM6/29/15
to Philip Jägenstedt, Ilya Grigorik, Ryan Sleevi, blink-dev, net-dev
On Mon, Jun 29, 2015 at 2:31 PM, Philip Jägenstedt <phi...@opera.com> wrote:
This is not my area of expertise, but I tried to follow the webkit-dev discussion:

The final message from Maciej is still largely negative, in my reading. Is implementation proceeding in WebKit and what do you think the chances of getting this shipped in WebKit are? (For those not following links, Yoav is driving the feature in WebKit too.)

I plan to continue and push the implementation in WebKit.
 

In that thread your said "That's up for the browser" and "it's skimpy on browser related details." Can't the spec just define everything so that we can get interoperable implementations? If the IETF doesn't allow you to for process reasons, perhaps another venue or a companion spec would be an option?

A "browser implementation" document is on my TODO list as a separate document from the spec.

Philip Jägenstedt

unread,
Jun 29, 2015, 5:58:24 PM6/29/15
to Yoav Weiss, Ilya Grigorik, Ryan Sleevi, blink-dev, net-dev
On Mon, Jun 29, 2015 at 5:17 PM, Yoav Weiss <yo...@yoav.ws> wrote:
On Mon, Jun 29, 2015 at 2:31 PM, Philip Jägenstedt <phi...@opera.com> wrote:
This is not my area of expertise, but I tried to follow the webkit-dev discussion:

The final message from Maciej is still largely negative, in my reading. Is implementation proceeding in WebKit and what do you think the chances of getting this shipped in WebKit are? (For those not following links, Yoav is driving the feature in WebKit too.)

I plan to continue and push the implementation in WebKit. 

Is that to say patches are landing, or is progress in WebKit effectively blocked on getting this into Blink? (Trying to figure out what to make of the reluctance shown on webkit-dev.)

In that thread your said "That's up for the browser" and "it's skimpy on browser related details." Can't the spec just define everything so that we can get interoperable implementations? If the IETF doesn't allow you to for process reasons, perhaps another venue or a companion spec would be an option?

A "browser implementation" document is on my TODO list as a separate document from the spec.

It sounds like this would effectively be part of the spec. What kinds of things would it say, how likely is it that requirements that come from this add-on spec would result in interesting feedback from other browser vendors?

(Off-topically, I'm also curious to know why it is a separate document, i.e. is it a natural layering corresponding to layers of the implementation, or is it just a process problem?)

Philip

Yoav Weiss

unread,
Jun 30, 2015, 3:22:14 AM6/30/15
to Philip Jägenstedt, Ilya Grigorik, Ryan Sleevi, blink-dev, net-dev
On Mon, Jun 29, 2015 at 10:58 PM, Philip Jägenstedt <phi...@opera.com> wrote:
On Mon, Jun 29, 2015 at 5:17 PM, Yoav Weiss <yo...@yoav.ws> wrote:
On Mon, Jun 29, 2015 at 2:31 PM, Philip Jägenstedt <phi...@opera.com> wrote:
This is not my area of expertise, but I tried to follow the webkit-dev discussion:

The final message from Maciej is still largely negative, in my reading. Is implementation proceeding in WebKit and what do you think the chances of getting this shipped in WebKit are? (For those not following links, Yoav is driving the feature in WebKit too.)

I plan to continue and push the implementation in WebKit. 

Is that to say patches are landing, or is progress in WebKit effectively blocked on getting this into Blink? (Trying to figure out what to make of the reluctance shown on webkit-dev.)

I have one in-flight patch, which was followed by further discussion. I'm hoping that after Blink support and usage in the wild (which will hopefully be followed by Gecko and Edge, both supportive of the feature), the use-case for the feature would be clearer to the WebKit folks.


In that thread your said "That's up for the browser" and "it's skimpy on browser related details." Can't the spec just define everything so that we can get interoperable implementations? If the IETF doesn't allow you to for process reasons, perhaps another venue or a companion spec would be an option?

A "browser implementation" document is on my TODO list as a separate document from the spec.

It sounds like this would effectively be part of the spec. What kinds of things would it say, how likely is it that requirements that come from this add-on spec would result in interesting feedback from other browser vendors?

I mostly want to specify things like:
* Where do the values of `Width` come from
* How does this spec play nicely with image preloading
* Reactivity to viewport changes
* etc


(Off-topically, I'm also curious to know why it is a separate document, i.e. is it a natural layering corresponding to layers of the implementation, or is it just a process problem?)

My understanding is that since the current spec is aimed to be an IETF spec, it should not include any details specific to browsers. I'll defer to Ilya for more details.

Philip Jägenstedt

unread,
Jun 30, 2015, 8:07:12 AM6/30/15
to Yoav Weiss, Ilya Grigorik, Ryan Sleevi, blink-dev, net-dev
On Tue, Jun 30, 2015 at 9:22 AM, Yoav Weiss <yo...@yoav.ws> wrote:
On Mon, Jun 29, 2015 at 10:58 PM, Philip Jägenstedt <phi...@opera.com> wrote:
On Mon, Jun 29, 2015 at 5:17 PM, Yoav Weiss <yo...@yoav.ws> wrote:
On Mon, Jun 29, 2015 at 2:31 PM, Philip Jägenstedt <phi...@opera.com> wrote:
This is not my area of expertise, but I tried to follow the webkit-dev discussion:

The final message from Maciej is still largely negative, in my reading. Is implementation proceeding in WebKit and what do you think the chances of getting this shipped in WebKit are? (For those not following links, Yoav is driving the feature in WebKit too.)

I plan to continue and push the implementation in WebKit. 

Is that to say patches are landing, or is progress in WebKit effectively blocked on getting this into Blink? (Trying to figure out what to make of the reluctance shown on webkit-dev.)

I have one in-flight patch, which was followed by further discussion. I'm hoping that after Blink support and usage in the wild (which will hopefully be followed by Gecko and Edge, both supportive of the feature), the use-case for the feature would be clearer to the WebKit folks.

OK, the feedback on the Content-DPR header thread was also rather skeptical, so we certainly shouldn't expect WebKit to take the lead on this. That's not encouraging, but need not block anything in Blink if we all agree that this is good stuff.

In that thread your said "That's up for the browser" and "it's skimpy on browser related details." Can't the spec just define everything so that we can get interoperable implementations? If the IETF doesn't allow you to for process reasons, perhaps another venue or a companion spec would be an option?

A "browser implementation" document is on my TODO list as a separate document from the spec.

It sounds like this would effectively be part of the spec. What kinds of things would it say, how likely is it that requirements that come from this add-on spec would result in interesting feedback from other browser vendors?

I mostly want to specify things like:
* Where do the values of `Width` come from
* How does this spec play nicely with image preloading
* Reactivity to viewport changes
* etc

Yes, where does the Width value come from? :)

Is this something that could be put together before this is shipped? Perhaps tentative support to ship first would be good so that you're not wasting your time.

Is the intent to flip ClientHints from status=experimental to stable? That would also enable some support for the Content-DPR header. It looks like that only affects layout and not HTMLImageElement.naturalWidth/Height, which seems wrong. There's no spec for it, but presumably you would want it to behave more like <video>, where there's videoWidth/Height that is consistently used in layout, canvas and APIs, and the actual pixel dimensions are unknown.

(Off-topically, I'm also curious to know why it is a separate document, i.e. is it a natural layering corresponding to layers of the implementation, or is it just a process problem?)

My understanding is that since the current spec is aimed to be an IETF spec, it should not include any details specific to browsers. I'll defer to Ilya for more details.

A spec-related question. Is the intention that servers begin to send the Accept-CH header and that clients then send these new headers with every request? I assume this has been discussed, but why aren't the new headers simply included in fetch contexts where are an image response is expected?

Will these additions have any effect at all when navigating directly to an image? It might be the first request to the server, and the response could be anything. If the response includes Accept-CH, might reloading cause another response to be sent the second time?

Philip, still hoping that an expert on all matters networking, image decoding and layout will jump in to set everything straight.

Yoav Weiss

unread,
Jun 30, 2015, 9:08:42 AM6/30/15
to Philip Jägenstedt, Ilya Grigorik, Ryan Sleevi, blink-dev, net-dev
On Tue, Jun 30, 2015 at 1:07 PM, Philip Jägenstedt <phi...@opera.com> wrote:
On Tue, Jun 30, 2015 at 9:22 AM, Yoav Weiss <yo...@yoav.ws> wrote:

I mostly want to specify things like:
* Where do the values of `Width` come from
* How does this spec play nicely with image preloading
* Reactivity to viewport changes
* etc

Yes, where does the Width value come from? :)

Markup signals, so the `width` and `sizes` attributes on the <img> element (or just `sizes` on <source> with a <picture> parent)
 

Is this something that could be put together before this is shipped? Perhaps tentative support to ship first would be good so that you're not wasting your time.

Is the intent to flip ClientHints from status=experimental to stable? That would also enable some support for the Content-DPR header.

Yes. Content-DPR support is part of the overall CH support for these hints (since the server needs a way to signal the browser that it acted upon the sent hints)
 
It looks like that only affects layout and not HTMLImageElement.naturalWidth/Height, which seems wrong.

Same is true for srcset and I have an open issue about that.
  
There's no spec for it, but presumably you would want it to behave more like <video>, where there's videoWidth/Height that is consistently used in layout, canvas and APIs, and the actual pixel dimensions are unknown.

(Off-topically, I'm also curious to know why it is a separate document, i.e. is it a natural layering corresponding to layers of the implementation, or is it just a process problem?)

My understanding is that since the current spec is aimed to be an IETF spec, it should not include any details specific to browsers. I'll defer to Ilya for more details.

A spec-related question. Is the intention that servers begin to send the Accept-CH header and that clients then send these new headers with every request?

Yes.
 
I assume this has been discussed, but why aren't the new headers simply included in fetch contexts where are an image response is expected?

One could argue that `DPR` and `Viewport-Width` may also be relevant to negotiate non-image resources. I have no problem with limiting the headers to image contexts at first, until we get a better feedback about usage.


Will these additions have any effect at all when navigating directly to an image?

Yes, assuming the server was already visited.
 
It might be the first request to the server, and the response could be anything. If the response includes Accept-CH, might reloading cause another response to be sent the second time?

That depends on the initial responses' caching headers.

Yoav Weiss

unread,
Jul 6, 2015, 2:13:42 AM7/6/15
to Philip Jägenstedt, Ilya Grigorik, Ryan Sleevi, blink-dev, net-dev
After off-list discussions with PhilipJ, I wrote up an initial draft of a browser implementation considerations document/spec.

Some of the conclusions we've reached:
* We should match the server-side inputs to the client side inputs, so it makes that the value of `Width` would translate directly to what we use for `srcset`. I've added such a reference in the spec. The 'width' attribute won't be a part of the initially expose `Width` value, until we would decide to add it to `srcset` as well. Therefore, I'm removing the `width` attribute support for the `Width` hints.
* We should further discuss the pros and cons of `Accept-CH`. It adds some complexity but on the other hand, it enables us to reduce request overhead in cases where the hints are not used by the servers.

Opinions on the latter would be appreciated :)


Philip Jägenstedt

unread,
Jul 6, 2015, 3:41:33 AM7/6/15
to Yoav Weiss, Ilya Grigorik, Ryan Sleevi, blink-dev, net-dev
There is an aspect of this that I realized only in discussion with Yoav. To quote the Accept-CH section of the new document: "User agents may also use the presence of the Accept-CH opt-in header in the response to the navigational request as a signal to send the various CH hints on sub-resource requests for that Document, including ones that are retrieved from third-party hosts."

The Blink implementation does track this per Document, and this seems like an unusual mode of content negotiation to me, that getting an Accept-CH header from one host can cause Width and Viewport-Width headers to be sent to another host.

The alternative that I think should be considered is to always send the new headers with image requests.

Philip

Ryan Sleevi

unread,
Jul 6, 2015, 10:25:56 AM7/6/15
to Philip Jägenstedt, Yoav Weiss, Ilya Grigorik, Ryan Sleevi, blink-dev, net-dev
On Mon, Jul 6, 2015 at 12:41 AM, Philip Jägenstedt <phi...@opera.com> wrote:
The alternative that I think should be considered is to always send the new headers with image requests.

I agree that this is a far more sensible approach.

Several thoughts, expressed elsewhere privately:
1) I'm concerned about W3C vs IETF process points again, and that the current route of the documents don't necessarily have the same level of expert review about the broader implications. I would hope, as a sign of standards maturity, there was some sign of IETF discussion/review/interest, perhaps in the case of preliminary expert review. More specifically, I want to make sure we're taking the "big picture" impact of HTTP flows :)

2) As this discussion has already captured, I think there's a lot in flux and a lot simply unknown / that will be bugged with these headers. My gut is still "here be dragons", and while I know it's unfair to those excited for it, I don't think I really have the time to dig in to figure out where they are and whether or not they're just very noisy lizards with projectors. However, by virtue of the purpose of these headers, we won't really get feedback / explore these sharp edge cases unless/until sites can start using/adopting this, and so we're in a chicken/egg problem.

For things Google is interested in, there's no question that teams frequently 'cheat' the process by whitelisting features/APIs for .google.com domains, and then use a mix of Finch & UMA (Googler only) to measure the impact, along with their implementation experience. I don't think that's a good state either, but it's at least a somewhat 'controlled' way of knowing you can remove a feature later (even if some Google teams end up making their infrastructure depend on some experimental feature such that it's not removable by Chromium developers :/). I know there was discussion in the past about enabling features 'conditionally' for users (50/50 splits and the like), although I'm not sure whatever happened to that or if that's now frowned upon.

I would say that given this variability, we should try to 'ship' it some place as minimal as possible, which is why I like the image context.

3) The Accept-CH issues raised by Philip are concerning, and definitely feel like added complexity and a constant source of future bugs. The alternative, sending the header on every request, is understandably undesirable for performance. One way to mitigate this would only be to enable this on HTTP/2 connections (thus benefit from HPACK), avoiding adding latency to HTTP/1 connections that would have to send this header on every (possibly image) request.

4) As with any/every change of networking, I'm concerned about the (public) ability to watch for performance regressions. For example, if it ended up that we were adding 60-80 bytes every request, and that ended up causing 1-2ms delays in requesting, I'm not confident that there's sufficient (public) infrastructure to capture that. Finch/UMA again are the traditional methods here, but the web-visible part makes this hard.

This is my long way of saying that, if we're ever going to do anything in this space, we're going to eventually have to ship it and see if it falls flat on its face / ruins the Internet. My hope is that we take as measured an approach as possible, sufficient to get feedback, and that we have strong ownership/sponsorship that is able to define the criteria to say 'no, we should pull this out', and not just the criteria to say 'yes', and look at how things turn out.

Yoav Weiss

unread,
Jul 7, 2015, 2:30:31 AM7/7/15
to Ryan Sleevi, Philip Jägenstedt, Ilya Grigorik, blink-dev, net-dev
OK, so according to the above, I propose the following changes:
* Eliminate `Accept-CH` response header
* Always send hints on image context requests
* (optional) Always send hints on navigational requests (to address the "user browsed to an image URL directly" use-case)

If that's acceptable, I'll go ahead with the code and documentation changes.

Ben Maurer

unread,
Jul 7, 2015, 2:53:30 AM7/7/15
to net...@chromium.org, blin...@chromium.org, phi...@opera.com, igri...@google.com, rsl...@chromium.org
If the header is going to be sent on all image requests (a fairly large number of requests), can it also be sent on requests for the main resource. Most web pages have much more than 1 image, so doing this wouldn't substantially increase the number of images. Doing so opens up a bunch of possibilities (eg, allowing a server to decide how much data to ship to the client in the initial request based on their viewport size).

mn...@mnot.net

unread,
Jul 7, 2015, 3:35:49 AM7/7/15
to blin...@chromium.org, rsl...@chromium.org, igri...@google.com, yo...@yoav.ws, phi...@opera.com, net...@chromium.org
Hey Ryan,

On Monday, July 6, 2015 at 11:25:56 PM UTC+9, Ryan Sleevi wrote:
 
1) I'm concerned about W3C vs IETF process points again, and that the current route of the documents don't necessarily have the same level of expert review about the broader implications. I would hope, as a sign of standards maturity, there was some sign of IETF discussion/review/interest, perhaps in the case of preliminary expert review. More specifically, I want to make sure we're taking the "big picture" impact of HTTP flows :)

We talked about this in our last WG meeting, and there was pretty strong interest. One of the blockers for adopting it has been waiting for Key; I'm thinking it might be good to decouple them (in the WG -- i.e., go ahead and start on CH) if that would help.

Ilya, WDYT? I'm happy to talk about it in Prague and do a call for adoption shortly thereafter.

 
2) As this discussion has already captured, I think there's a lot in flux and a lot simply unknown / that will be bugged with these headers. My gut is still "here be dragons", and while I know it's unfair to those excited for it, I don't think I really have the time to dig in to figure out where they are and whether or not they're just very noisy lizards with projectors. However, by virtue of the purpose of these headers, we won't really get feedback / explore these sharp edge cases unless/until sites can start using/adopting this, and so we're in a chicken/egg problem.

For things Google is interested in, there's no question that teams frequently 'cheat' the process by whitelisting features/APIs for .google.com domains, and then use a mix of Finch & UMA (Googler only) to measure the impact, along with their implementation experience. I don't think that's a good state either, but it's at least a somewhat 'controlled' way of knowing you can remove a feature later (even if some Google teams end up making their infrastructure depend on some experimental feature such that it's not removable by Chromium developers :/). I know there was discussion in the past about enabling features 'conditionally' for users (50/50 splits and the like), although I'm not sure whatever happened to that or if that's now frowned upon.

I would say that given this variability, we should try to 'ship' it some place as minimal as possible, which is why I like the image context.

3) The Accept-CH issues raised by Philip are concerning, and definitely feel like added complexity and a constant source of future bugs. The alternative, sending the header on every request, is understandably undesirable for performance. One way to mitigate this would only be to enable this on HTTP/2 connections (thus benefit from HPACK), avoiding adding latency to HTTP/1 connections that would have to send this header on every (possibly image) request.

I think this should be discussed. Sending a header on every request isn't necessarily a deal-breaker with HTTP/1 if it's small, and some people may even feel that it's OK to give people an incentive to move to /2.

 
4) As with any/every change of networking, I'm concerned about the (public) ability to watch for performance regressions. For example, if it ended up that we were adding 60-80 bytes every request, and that ended up causing 1-2ms delays in requesting, I'm not confident that there's sufficient (public) infrastructure to capture that. Finch/UMA again are the traditional methods here, but the web-visible part makes this hard.

This is my long way of saying that, if we're ever going to do anything in this space, we're going to eventually have to ship it and see if it falls flat on its face / ruins the Internet. My hope is that we take as measured an approach as possible, sufficient to get feedback, and that we have strong ownership/sponsorship that is able to define the criteria to say 'no, we should pull this out', and not just the criteria to say 'yes', and look at how things turn out.

I think we're getting to a place where that should be apparent in RUM data, and other folks can collect that (with some work). /me looks at Yoav...

Giving sites control over when the browser uses these features helps collect that data. I hear what you're saying about Accept-CH. What about having a well-known location that holds site-wide metadata like this, so that the browser can request it on a background thread in a non-blocking fashion (sending the header until it knows the site hasn't opted out)? Every time this sort of approach has come up before, browsers have been reluctant to make that other request, but I figure eventually there'll be enough interesting use cases to top the balance.

For HTTP/2, it's simpler, of course; you could just define a SETTING that opts the site out of the header. 

Just thinking out loud...

 

Ryan Sleevi

unread,
Jul 7, 2015, 3:42:12 AM7/7/15
to Ben Maurer, net-dev, blink-dev, Philip Jägenstedt, Ilya Grigorik, Ryan Sleevi
On Mon, Jul 6, 2015 at 11:53 PM, Ben Maurer <ben.m...@gmail.com> wrote:
If the header is going to be sent on all image requests (a fairly large number of requests), can it also be sent on requests for the main resource. Most web pages have much more than 1 image, so doing this wouldn't substantially increase the number of images. Doing so opens up a bunch of possibilities (eg, allowing a server to decide how much data to ship to the client in the initial request based on their viewport size).

I'd much rather proceed more cautiously.

We already have interesting Loader bugs cropping up with Client-Hints ( e.g. https://code.google.com/p/chromium/issues/detail?id=502980 ) and my gut is that the sort of inter-relation between document loads, image loads, and variances are already going to stress the ability to sort these out in a timely manner without impairing users too much.

When I say cautiously, I'm talking about rolling out after a release or two once we're sure we haven't botched the low-hanging fruit.

Ryan Sleevi

unread,
Jul 7, 2015, 3:49:00 AM7/7/15
to Mark Nottingham, blink-dev, Ryan Sleevi, Ilya Grigorik, Yoav Weiss, Philip Jägenstedt, net-dev
On Tue, Jul 7, 2015 at 12:35 AM, <mn...@mnot.net> wrote:
I think this should be discussed. Sending a header on every request isn't necessarily a deal-breaker with HTTP/1 if it's small, and some people may even feel that it's OK to give people an incentive to move to /2.

The problem is death by a thousand cuts that quickly add up.

We've already seen issues caused by one recent header addition ("HTTPS: 1") - https://code.google.com/p/chromium/issues/detail?id=505268 - and I'm concerned both in the 'death by a thousand cuts' scenario and in the 'increasing number of permutations that cause weird server behaviours'
 
Giving sites control over when the browser uses these features helps collect that data. I hear what you're saying about Accept-CH. What about having a well-known location that holds site-wide metadata like this, so that the browser can request it on a background thread in a non-blocking fashion (sending the header until it knows the site hasn't opted out)? Every time this sort of approach has come up before, browsers have been reluctant to make that other request, but I figure eventually there'll be enough interesting use cases to top the balance.

I was wondering when you'd chime in on this ;)

I think we're still quite loathe to do the 'favicon.ico' background requests. Background requests in general (whether for SDCH or, for that matter, for favicon, which is quasi-background) already tickle out entire new codepaths of weirdness. See the recent Stale-While-Revalidate discussion on net-dev, or some of the discussions regarding Web Push, to see that in many cases, this opens a new can of worms.

Much like chrome://flags, I think we should be generally hesitant towards features that can't be safely turned on by default, and be generally loathe towards adding more flags (whether they're controlled locally by a user or remotely by a site). I realize that 'negotiation' is objectively different in some ways, but I think the same underlying concerns - complexity, code paths, edge cases - still very much applies.

I think we've got enough options on the table to avoid the need to consider such a thing, and as I've mentioned elsewhere, I'm not quite keen to introduce yet another way of trying to scope authority and the many complexities that come in (with every flag, the question is "Who is authorized to set this" and "What are the implications if they do" come up, especially if there's only one path to set these)

Hopefully, with just an image-context only sending, we can start to get feedback from operators and developers about the savings and performance challenges, and then look to expose it wider (as Ben requested) if the complexity/cost metrics pay out.

Philip Jägenstedt

unread,
Jul 7, 2015, 4:42:58 AM7/7/15
to Ryan Sleevi, Ben Maurer, net-dev, blink-dev, Ilya Grigorik
One way to limit the impact would be to start out by only sending the new headers for image requests over HTTPS, or perhaps for secure origins if it's easy to check whether it's a secure origin before deciding which headers to send. Not because this is a powerful feature (is it?) but because it would reduce the number of servers that are exposed to the new headers, and with header compression it wouldn't bloat the requests as much. Would that make any sense?

Philip

Philip Jägenstedt

unread,
Jul 7, 2015, 4:58:39 AM7/7/15
to Yoav Weiss, Ryan Sleevi, Ilya Grigorik, blink-dev, net-dev
The first two points sound good to me. What precisely counts as an image context, though? Is it the "image" and "imageset" contexts in Fetch, requests that are categorized as "img-src" in CSP, or something else?

The third is not so obvious, it would be similar to always sending a "Range: bytes=0-" header with navigational requests to improve the case when it's a video. I'd lean towards not doing that until it's more clear that there's a problem.

There is one more thing we discussed on IRC that would be good to capture on the list: what is the use case for sending the Viewport-Width header? Since Width would match Viewport-Width in the absence of the sizes attribute, when would one take Viewport-Width into account in addition to Width?

Philip

Yoav Weiss

unread,
Jul 7, 2015, 8:17:29 AM7/7/15
to Philip Jägenstedt, Ryan Sleevi, Ilya Grigorik, blink-dev, net-dev
On Tue, Jul 7, 2015 at 9:58 AM, Philip Jägenstedt <phi...@opera.com> wrote:
On Tue, Jul 7, 2015 at 8:30 AM, Yoav Weiss <yo...@yoav.ws> wrote:
 
OK, so according to the above, I propose the following changes:
* Eliminate `Accept-CH` response header
* Always send hints on image context requests
* (optional) Always send hints on navigational requests (to address the "user browsed to an image URL directly" use-case)

If that's acceptable, I'll go ahead with the code and documentation changes.

The first two points sound good to me. What precisely counts as an image context, though? Is it the "image" and "imageset" contexts in Fetch, requests that are categorized as "img-src" in CSP, or something else?

I'm fine with either.
 

The third is not so obvious, it would be similar to always sending a "Range: bytes=0-" header with navigational requests to improve the case when it's a video. I'd lean towards not doing that until it's more clear that there's a problem.

OK.
 

There is one more thing we discussed on IRC that would be good to capture on the list: what is the use case for sending the Viewport-Width header? Since Width would match Viewport-Width in the absence of the sizes attribute, when would one take Viewport-Width into account in addition to Width?

`Width` is not sent when there's no `sizes` attribute. Viewport-Width is sent in all cases, and can be used as a weaker hint in the absence of the stronger hint which is `Width`. 

Yoav Weiss

unread,
Jul 7, 2015, 8:21:14 AM7/7/15
to Philip Jägenstedt, Ryan Sleevi, Ben Maurer, net-dev, blink-dev, Ilya Grigorik
I wouldn't consider the feature a "powerful" one, and limiting the feature to HTTPS would definitely impact adoption. With that said, if necessary, I'm fine with rolling it first to HTTPS, and extending to HTTP once we gain more field experience, in a release or two.

Philip Jägenstedt

unread,
Jul 7, 2015, 9:14:28 AM7/7/15
to Yoav Weiss, Ryan Sleevi, Ilya Grigorik, blink-dev, net-dev
Would it make sense for Width to fall back to the viewport width in the absence of the sizes attribute? I think this would correspond to "If the above algorithm exhausts unparsed sizes list without returning a size value, return 100vw" in parse a sizes attribute.

As discussed elsewhere, it would amount to using only the output of a shared algorithm both in the client-side algorithm and in server-side implementations. To send both one of the inputs and the output of the algorithm to the server makes we wonder what the server will do with the extra information that isn't done on the client.

Philip

Yoav Weiss

unread,
Jul 7, 2015, 9:39:31 AM7/7/15
to Philip Jägenstedt, Ryan Sleevi, Ilya Grigorik, blink-dev, net-dev
This is how it was defined before comments from Apple suggested that it'd be better to split the values up, so that the server side has a better notion of the value it is getting.

Philip Jägenstedt

unread,
Jul 7, 2015, 10:06:29 AM7/7/15
to Yoav Weiss, Ryan Sleevi, Ilya Grigorik, blink-dev, net-dev
Do you agree that it is better to split them up? If the Width header is always sent and defaults to the viewport width, I don't quite see what one would do with the additional header. It looks like a feature to work around broken markup, which would be odd unless there's a truly huge amount of broken markup out there that cannot be fixed.

Philip

Yoav Weiss

unread,
Jul 7, 2015, 12:01:34 PM7/7/15
to Philip Jägenstedt, Ryan Sleevi, Ilya Grigorik, blink-dev, net-dev
On Tue, Jul 7, 2015 at 3:06 PM, Philip Jägenstedt <phi...@opera.com> wrote:
On Tue, Jul 7, 2015 at 3:39 PM, Yoav Weiss <yo...@yoav.ws> wrote:


On Tue, Jul 7, 2015 at 2:14 PM, Philip Jägenstedt <phi...@opera.com> wrote:
On Tue, Jul 7, 2015 at 2:17 PM, Yoav Weiss <yo...@yoav.ws> wrote:
On Tue, Jul 7, 2015 at 9:58 AM, Philip Jägenstedt <phi...@opera.com> wrote:
On Tue, Jul 7, 2015 at 8:30 AM, Yoav Weiss <yo...@yoav.ws> wrote:
 
OK, so according to the above, I propose the following changes:
* Eliminate `Accept-CH` response header
* Always send hints on image context requests
* (optional) Always send hints on navigational requests (to address the "user browsed to an image URL directly" use-case)

If that's acceptable, I'll go ahead with the code and documentation changes.

The first two points sound good to me. What precisely counts as an image context, though? Is it the "image" and "imageset" contexts in Fetch, requests that are categorized as "img-src" in CSP, or something else?

I'm fine with either.
 

The third is not so obvious, it would be similar to always sending a "Range: bytes=0-" header with navigational requests to improve the case when it's a video. I'd lean towards not doing that until it's more clear that there's a problem.

OK.
 

There is one more thing we discussed on IRC that would be good to capture on the list: what is the use case for sending the Viewport-Width header? Since Width would match Viewport-Width in the absence of the sizes attribute, when would one take Viewport-Width into account in addition to Width?

`Width` is not sent when there's no `sizes` attribute. Viewport-Width is sent in all cases, and can be used as a weaker hint in the absence of the stronger hint which is `Width`. 

Would it make sense for Width to fall back to the viewport width in the absence of the sizes attribute? I think this would correspond to "If the above algorithm exhausts unparsed sizes list without returning a size value, return 100vw" in parse a sizes attribute.

As discussed elsewhere, it would amount to using only the output of a shared algorithm both in the client-side algorithm and in server-side implementations. To send both one of the inputs and the output of the algorithm to the server makes we wonder what the server will do with the extra information that isn't done on the client.

 
This is how it was defined before comments from Apple suggested that it'd be better to split the values up, so that the server side has a better notion of the value it is getting.

Do you agree that it is better to split them up?

Splitting them up has advantages since the server can know if it has received the exact image dimensions, and use that as a stronger signal.
The advantages are not huge though, and it's true that keeping it a mirror of the `sizes` logic would be cleaner.

Ilya - WDYT?

Ben Maurer

unread,
Jul 7, 2015, 12:25:27 PM7/7/15
to Ryan Sleevi, net-dev, blink-dev, Philip Jägenstedt, Ilya Grigorik
Do you have a specific sense of the risks that implementing this on the main request (vs just images) would bring. From the point of view of a website provider, if we find that the Client Hint headers are inaccurate, we'd just ignore them on browser versions known to be bad.

I'm all for launching this cautiously, just curious what kinds of risks you see in sending on the main document and how those would be debugged by doing a softer launch.

-b

Ilya Grigorik

unread,
Jul 8, 2015, 11:12:49 AM7/8/15
to Ben Maurer, Ryan Sleevi, net-dev, blink-dev, Philip Jägenstedt
(apologies about the slow reply... been away, catching up)

On Tue, Jul 7, 2015 at 12:35 AM, <mn...@mnot.net> wrote:
1) I'm concerned about W3C vs IETF process points again, and that the current route of the documents don't necessarily have the same level of expert review about the broader implications. I would hope, as a sign of standards maturity, there was some sign of IETF discussion/review/interest, perhaps in the case of preliminary expert review. More specifically, I want to make sure we're taking the "big picture" impact of HTTP flows :)

We talked about this in our last WG meeting, and there was pretty strong interest. One of the blockers for adopting it has been waiting for Key; I'm thinking it might be good to decouple them (in the WG -- i.e., go ahead and start on CH) if that would help.

Ilya, WDYT? I'm happy to talk about it in Prague and do a call for adoption shortly thereafter.

sgtm. CH is not dependent on Key.. But it would benefit from it.

Re, scoping when & where CH headers are sent: 
1) Sending DPR/Width for non-image resources is a valid and important use case: many sites rely on this type of functionality to deliver optimized markup (CSS, JS, etc). There is no reason to prohibit this.
2) I don't think there is anything wrong with Accept-CH enabling headers for resources on third-party origins (used in context of that document). Upgrade-insecure-requests has same semantics.
3) To limit overhead when we first ship this I propose sticking to making this a strictly opt-in feature (as currently specced):
-- The site must provide Accept-CH or equivalent <meta http-equiv>
-- Yes this means direct navigations won't trigger CH hints, but all subresource requests will; I think this is a good tradeoff.
-- Nothing stops us from adding persistence later, once we prove the value and impact.

ig

Ryan Sleevi

unread,
Jul 8, 2015, 11:17:29 AM7/8/15
to Ben Maurer, Ryan Sleevi, net-dev, blink-dev, Philip Jägenstedt, Ilya Grigorik, Dominic Battre
On Tue, Jul 7, 2015 at 9:25 AM, Ben Maurer <ben.m...@gmail.com> wrote:
Do you have a specific sense of the risks that implementing this on the main request (vs just images) would bring. From the point of view of a website provider, if we find that the Client Hint headers are inaccurate, we'd just ignore them on browser versions known to be bad.

I'm all for launching this cautiously, just curious what kinds of risks you see in sending on the main document and how those would be debugged by doing a softer launch.

Well, like I mentioned earlier, we've already seen some challenge/confusion with those using C-H causing undesirable user behaviour ( c.f. https://code.google.com/p/chromium/issues/detail?id=502980 ). There's also the Width/Viewport-Width bits yet TBD, but which getting it sorted for images may be easier. Similar to the "HTTPS: 1" header causing issues, by limiting the contexts in which we're sending this, we've got a potential of breaking fewer sites if they somehow happened to rely on the header.

On the client side, the breakage caused by weirdnesses with respect to the Cache for <img> tags will be less than the breakages caused by weirdness for main documents (that is, better to have botched images than a botched page, right?). The document has the whole signalling issue with Accept-CH, which we can already see.

On the privacy side, I think Accept-CH being able to induce user viewport leakage to third-party passive content is quite questionable. I'd like to better understand the information leakage here to third-parties, especially since http://igrigorik.github.io/http-client-hints/ doesn't seem to mention privacy at all. By avoiding it for the main document in the initial implementation, we give more time to have the privacy discussion while perhaps mitigating some of those concerns.

Ilya Grigorik

unread,
Jul 8, 2015, 11:32:05 AM7/8/15
to Ryan Sleevi, Ben Maurer, net-dev, blink-dev, Philip Jägenstedt, Dominic Battre
On Wed, Jul 8, 2015 at 8:17 AM, Ryan Sleevi <rsl...@chromium.org> wrote:
On the client side, the breakage caused by weirdnesses with respect to the Cache for <img> tags will be less than the breakages caused by weirdness for main documents (that is, better to have botched images than a botched page, right?). The document has the whole signalling issue with Accept-CH, which we can already see.

Note that original route (opt-in via Accept-CH) would *not* emit hints for main document: the presence of the opt-in is a signal to emit hints for subresource requests.
 
On the privacy side, I think Accept-CH being able to induce user viewport leakage to third-party passive content is quite questionable. I'd like to better understand the information leakage here to third-parties, especially since http://igrigorik.github.io/http-client-hints/ doesn't seem to mention privacy at all. By avoiding it for the main document in the initial implementation, we give more time to have the privacy discussion while perhaps mitigating some of those concerns.

As proposed, the headers are opt-in and would only be sent if the site explicitly tells us to. IMO, this is the best place to start: it enables the key use cases for those that want to experiment with them and avoids overhead/leakage for those who do not care about it. 

Re, sending hints to third-party origins: this is critical, as many/most image and other assets are hosted on static CDNs and/or optimization services (also, sharding..).

ig

Ryan Sleevi

unread,
Jul 8, 2015, 12:38:56 PM7/8/15
to Ilya Grigorik, Ryan Sleevi, Ben Maurer, net-dev, blink-dev, Philip Jägenstedt, Dominic Battre
On Wed, Jul 8, 2015 at 8:31 AM, Ilya Grigorik <igri...@google.com> wrote:
Re, sending hints to third-party origins: this is critical, as many/most image and other assets are hosted on static CDNs and/or optimization services (also, sharding..).

Considering how much work is being spent on resolving linkability between first-party and third-party contexts, and considering that this passively leaks information (Viewport-Width) that is [seemingly?] otherwise unavailable except for active script, this does seem to be a strange privacy tradeoff.

Perhaps you can add a Privacy Considerations section? ;) [The same applies to DPR & Downlink]. Perhaps thinking about the questions posed by https://w3ctag.github.io/security-questionnaire/ ?

Yoav Weiss

unread,
Jul 8, 2015, 12:50:23 PM7/8/15
to Ryan Sleevi, Ilya Grigorik, Ben Maurer, net-dev, blink-dev, Philip Jägenstedt, Dominic Battre
On Wed, Jul 8, 2015 at 5:38 PM, Ryan Sleevi <rsl...@chromium.org> wrote:
On Wed, Jul 8, 2015 at 8:31 AM, Ilya Grigorik <igri...@google.com> wrote:
Re, sending hints to third-party origins: this is critical, as many/most image and other assets are hosted on static CDNs and/or optimization services (also, sharding..).

Considering how much work is being spent on resolving linkability between first-party and third-party contexts, and considering that this passively leaks information (Viewport-Width) that is [seemingly?] otherwise unavailable except for active script, this does seem to be a strange privacy tradeoff.

Can you detail the leak scenario?
Assuming we're OK with communicating viewport width to Web sites (which has been possible to do in JS since forever), how are `Accept-CH`+`Viewport-Width` resulting in further info leaks?

Ilya Grigorik

unread,
Jul 8, 2015, 5:39:18 PM7/8/15
to Ryan Sleevi, Ben Maurer, net-dev, blink-dev, Philip Jägenstedt, Dominic Battre
On Wed, Jul 8, 2015 at 9:38 AM, Ryan Sleevi <rsl...@chromium.org> wrote:
On Wed, Jul 8, 2015 at 8:31 AM, Ilya Grigorik <igri...@google.com> wrote:
Re, sending hints to third-party origins: this is critical, as many/most image and other assets are hosted on static CDNs and/or optimization services (also, sharding..).

Considering how much work is being spent on resolving linkability between first-party and third-party contexts, and considering that this passively leaks information (Viewport-Width) that is [seemingly?] otherwise unavailable except for active script, this does seem to be a strange privacy tradeoff.

Note that the current "state of art" is to embed a script that queries the document for same information and then dynamically inject IMG (or whatever else) tags that contain this data in the URL path or query string -- e.g. every wordpress.com hosted site does exactly this to help automate+optimize image delivery from their image CDN, albeit with the obvious downside that image fetches are blocked on JavaScript. CH removes the JS penalty and removes the need for such scripts.

That said, yes I do agree that we need to carefully consider how we enable this type of functionality such that we don't unnecessarily expose such data to origins that don't want it or need it. This is why I keep coming back to deploying CH via opt-in behavior.
 
Perhaps you can add a Privacy Considerations section? ;) [The same applies to DPR & Downlink]. Perhaps thinking about the questions posed by https://w3ctag.github.io/security-questionnaire/ ?

Mark Nottingham

unread,
Jul 9, 2015, 4:03:39 AM7/9/15
to rsl...@chromium.org, blink-dev, Ilya Grigorik, Yoav Weiss, Philip Jägenstedt, net-dev

> On 7 Jul 2015, at 3:48 pm, Ryan Sleevi <rsl...@chromium.org> wrote:
>
>
>
> On Tue, Jul 7, 2015 at 12:35 AM, <mn...@mnot.net> wrote:
> I think this should be discussed. Sending a header on every request isn't necessarily a deal-breaker with HTTP/1 if it's small, and some people may even feel that it's OK to give people an incentive to move to /2.
>
> The problem is death by a thousand cuts that quickly add up.

You say "death by a thousand cuts", I say "slippery slope fallacy' :)


> We've already seen issues caused by one recent header addition ("HTTPS: 1") - https://code.google.com/p/chromium/issues/detail?id=505268 - and I'm concerned both in the 'death by a thousand cuts' scenario and in the 'increasing number of permutations that cause weird server behaviours'
>
> Giving sites control over when the browser uses these features helps collect that data. I hear what you're saying about Accept-CH. What about having a well-known location that holds site-wide metadata like this, so that the browser can request it on a background thread in a non-blocking fashion (sending the header until it knows the site hasn't opted out)? Every time this sort of approach has come up before, browsers have been reluctant to make that other request, but I figure eventually there'll be enough interesting use cases to top the balance.
>
> I was wondering when you'd chime in on this ;)
>
> I think we're still quite loathe to do the 'favicon.ico' background requests. Background requests in general (whether for SDCH or, for that matter, for favicon, which is quasi-background) already tickle out entire new codepaths of weirdness. See the recent Stale-While-Revalidate discussion on net-dev, or some of the discussions regarding Web Push, to see that in many cases, this opens a new can of worms.

Totally agree and know where you're coming from — but I suspect that the aggregate value of making one such request for browsers will *eventually* overcome this reluctance. HTTP/2 Settings *do* get us some of the way there, and I sometimes wonder if settings (or a subset of them) could be made isomorphic to a .well-known resource in a helpful way...

BTW, SwR was a total pain in the ass for intermediary vendors too.


> Much like chrome://flags, I think we should be generally hesitant towards features that can't be safely turned on by default, and be generally loathe towards adding more flags (whether they're controlled locally by a user or remotely by a site). I realize that 'negotiation' is objectively different in some ways, but I think the same underlying concerns - complexity, code paths, edge cases - still very much applies.

In this particular case, the control wasn't being introduced for safety - it's so the site can opt out of getting the extra bits in HTTP/1 if they're crazy-concerned about the bandwidth implications. I agree that's pretty weak justification for the additional mechanism, and would be fine with always sending it (for all requests or just for some types) if others are.


> I think we've got enough options on the table to avoid the need to consider such a thing, and as I've mentioned elsewhere, I'm not quite keen to introduce yet another way of trying to scope authority and the many complexities that come in (with every flag, the question is "Who is authorized to set this" and "What are the implications if they do" come up, especially if there's only one path to set these)
>
> Hopefully, with just an image-context only sending, we can start to get feedback from operators and developers about the savings and performance challenges, and then look to expose it wider (as Ben requested) if the complexity/cost metrics pay out.

--
Mark Nottingham https://www.mnot.net/




Philip Jägenstedt

unread,
Jul 14, 2015, 11:07:05 AM7/14/15
to Mark Nottingham, Ryan Sleevi, blink-dev, Ilya Grigorik, Yoav Weiss, net-dev
I'm not sure who's waiting for whom at this point. Yoav, are you
having any off-list discussions, or waiting for feedback here?
> To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

igri...@google.com

unread,
Aug 12, 2015, 10:49:44 AM8/12/15
to blink-dev, mn...@mnot.net, rsl...@chromium.org, igri...@google.com, yo...@yoav.ws, net...@chromium.org
For posterity.. This thread got forked, continuation: 
Reply all
Reply to author
Forward
0 new messages