Intent to Implement and Ship: RQ client hints header

[Matt Welsh]

Contact emails

m...@chromium.org, be...@chromium.org, igri...@chromium.org, si...@chromium.org

Spec

http://igrigorik.github.io/http-client-hints/#the-rq-client-hint

Summary

This change introduces use of a new HTTP request header "RQ" that indicates a desired quality level for the requested resource. We intend to implement a single value for RQ, "low", which indicates to the origin (or proxy) that a lower quality version of the resource is requested, due to poor network conditions, network cost, or other criteria - e.g. “Chrome Data Saver” option was enabled by the user. The meaning of the communicated value is deferred to the server, which may use the value to select an optimized resource variant based on availability, encoding costs, and other criteria.

Additional background: https://docs.google.com/document/d/1YAqkbf6VQhtnrHd7z1Jrpb5WtObUZL8gsU6v42qHlWQ/edit

Motivation

Users on very slow networks (e.g., 2G) sometimes must wait too long for high fidelity pages to load, and users on very expensive networks sometimes must pay too much to retrieve high fidelity content. An origin or transcoding proxy that receives the RQ header can improve page load time and/or reduce costs by returning a lower fidelity version of the requested resource. In both cases, we expect an improved user experience with the RQ header, and consequently, more use of the Web.

Compatibility risk

We expect origins and proxies that do not support RQ to simply ignore the request header.

Ongoing technical constraints

None.

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

Yes.

OWP launch tracking bug?

http://crbug.com/485640

Link to entry on the feature dashboard

https://www.chromestatus.com/features/5504430086553600

Requesting approval to ship?

Yes

[Ryan Sleevi]

This isn't just about the RQ client hints - this also covers the
Alternate-Content-Length header, which seems to have been specified
only a few hours ago -
https://github.com/igrigorik/http-client-hints/pull/42

(Strictly speaking, it was 6 days ago -
https://github.com/igrigorik/http-client-hints/pull/39#issuecomment-99249747
- but we're splitting hairs here)

The signals from other browsers (besides Opera) seem highly mixed,
with nothing strong, at least from the dashboard. What's to ensure
this doesn't become a Chrome-specific feature? What are the success
criteria for this - and how strongly are we committed to removing it
if other browsers fail to adopt?

I ask because for things involving the "Chrome Data Saver" proxy, the
ability of Chrome to be responsible and spec-respecting in necessary
features has often lagged considerably due to server-side
considerations (Via header, HTTP/2 CONNECT method, custom headers
unspecified).

To put a more concrete point on the question:
- From an impact side from servers, we claim that removing the RQ
header should be a no-op (since there's plenty of clients that don't
support it)
- From an impact side for Chrome, what would prevent us from removing it?
- Ex. If we saw a 30% improvement in compression rates, but zero
interest from other UAs, would we continue to ship it?
- Ex. If we saw a 5% improvement in compression rates, but zero
interest from other UAs, would we continue to ship it?
- Ex. if we saw a 25% improvement in compression rates, but interest
from other UAs was conditioned on changing the semantics, when and how
would we implement the different semantics?

I'm all for experimentation, but I think the historic evidence is that
we'll be hard-pressed to remove or change this once we add it, and
that makes me nervous given the weak signals, because that seems to
represent a real interop risk.

> --
> 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/CAGz5krrg16QCyoO0fQxRr6Z4v6vzVk9sVNGfrp407_-yVFcSog%40mail.gmail.com.

[David Tapuska]

You might get somewhere with this if you wrote a nginx module/filter which would be pretty trivial. But you'd need to write some type of tool to generate content for those keys...

WRT the alternate content length...

A few problems I see:

1) Returning the alternate content length; how do you trust the server to present correct metrics?

2) Is the content length before compression? There are some websites that return BMPs; but actually gzip the response. (ie; there is a large deviation of the bytes over the wire vs content length of response).

3) Implementing this in the server as a filter would likely require 2 fstat calls; which I'd be reluctant to do on the server as it yields no net benefit for the server. If I was writing a module for nginx; I'd just skip returning the alternate content length and just purely implement this like a gzip module.

For a proxy that you control; you can force the headers to be specific values; I just don't know if getting metrics from a website you don't trust to drive your metrics makes sense.

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

[Nat Duca]

How does this relate to our thinking around appendAsync/elements-that-have-defer/non-urgent elements? Elliot, do we have a doc for that?

Is this just a bit that the upper levels of the platform could automatically set when we encounter lower importance content? Or is this something the author has to intentionally ask for? What's the big picture narrative here that we're working toward?

[Matt Welsh]

Ryan,

I'll let +Jonny Rein Eriksen and +haavardm at work comment on Opera's plans; we've had a separate and lengthy discussion with them on this and my understanding is that Opera is on board with this proposal. Whatever you are looking at probably does not reflect the full discussion we've had.

What criteria has Chrome used for maintaining similar features in the past? This is a bit unlike something like SPDY or QUIC (which did not initially require buy-in from non-Chrome browsers). I'm happy to settle on some set of success criteria by which we decide to revert this change. In general I would expect to see uptake both in non-Chrome browsers as well as some usage by websites, though I don't expect the latter to happen overnight, and we have to start somewhere. This is not unlike a new JS API which nobody is using because it does not exist yet.

Matt

[Matt Welsh]

We've discussed adding support for this to mod_pagespeed, which would be fairly straightforward.

To answer your questions about content length:

- I see no way of knowing whether the server is returning truthful results for Alternate-Content-Length. At the same time there is little incentive for a server to lie about it. It's only intended to be informative to the user.

- Alternate-Content-Length has the same meaning as the Content-Length header, which is supposed to represent the number of bytes "on the wire" after applying content-encodings like gzip. Your example ("Large deviation of bytes over the wire vs content length of response" for BMP with content-encoding: gzip) is not accurate.

- A server is welcome not to send Alternate-Content-Length if it is unable or unwilling to do so; again, it's purely for informational purposes.

Matt

[Matt Welsh]

Nat,

The big picture is allowing browsers to convey a clear signal to sites that they wish to receive (possibly) degraded content for the sake of improving speed or reducing data usage. I don't think this has any bearing on the site author. In Chrome the intention is to link this to the already-launched Data Saver user setting.

Matt

[Ryan Hamilton]

On Mon, May 11, 2015 at 3:17 PM, 'Matt Welsh' via net-dev <net...@chromium.org> wrote:

What criteria has Chrome used for maintaining similar features in the past? This is a bit unlike something like SPDY or QUIC (which did not initially require buy-in from non-Chrome browsers).

​I think that neither SPDY nor QUIC would have happened with the new process.​

Cheers,

Ryan

[Ryan Sleevi]

On Mon, May 11, 2015 at 3:17 PM, Matt Welsh <m...@google.com> wrote:

> What criteria has Chrome used for maintaining similar features in the past?
> This is a bit unlike something like SPDY or QUIC (which did not initially
> require buy-in from non-Chrome browsers). I'm happy to settle on some set of
> success criteria by which we decide to revert this change. In general I
> would expect to see uptake both in non-Chrome browsers as well as some usage
> by websites, though I don't expect the latter to happen overnight, and we
> have to start somewhere. This is not unlike a new JS API which nobody is
> using because it does not exist yet.

The process in the past has been problematic, and has lead to a
variety of Google-specific features being shipped in Chrome and
becoming depended on by external sites. Overall, that's a net-negative
for the web, even if it results in short-term positives.

The result of this was the thread last month -
https://groups.google.com/a/chromium.org/d/msg/net-dev/u8R11HBmaOk/0rOFvsD_Fj0J
- which you're following.

It doesn't say that progress can't be made, but it seeks to balance
the risks to the web platform with the gains from flexibility. Many of
the questions I asked are specifically trying to gauge the
compatibility risk to the Web platform as a whole if we proceed with
this. I am very much concerned with the compatibility risk of this
feature, especially given past compatibility risks, so I think it's
worth having that discussion.

[Chris Bentzel]

Matt - thanks for going through the Blink process for networking features.

This is the first feature to go through the process, and we'll probably learn a lot even if it will be a tad bit bumpier the first time.

--
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/CACvaWvYDh5oD%2BtKQO1qrjB%3DS23iNA8FaWVRdv6aGod0qVM4fFQ%40mail.gmail.com.

[Matt Welsh]

Yes, I appreciate your concerns very much. So the question is what can we do to explore this approach? As I said, happy to have some criteria for killing it off if it is not successful, and I very much want to avoid it being Google-specific.

Matt

[Jonny Rein Eriksen]

On 12.05.2015 00:17, Matt Welsh wrote:

Ryan,

I'll let +Jonny Rein Eriksen and +haavardm at work comment on Opera's plans; we've had a separate and lengthy discussion with them on this and my understanding is that Opera is on board with this proposal. Whatever you are looking at probably does not reflect the full discussion we've had.

We are definitely supportive and would like to use this for both Opera Turbo and Opera Mini. It should make sense for Opera Rocket and Opera Max as well, which are our other compression products.

Regarding Alternate-Content-Length and the cost of implementing that: I believe that for us it would be seen as a header that does not have to be very accurate, so for any content it could be enough if it indicated the relative expected saving. If youtube in RQ:low mode gave 30% savings, then use that for all calculations of this. What we want to use it for is to indicate how much data a user saved by using a compression mode. Our current Turbo data saving numbers are under-reporting quite a lot, and I believe with optional Alternate-Content-Length that would also be the case for RQ:low. Which is probably fine.

Jonny

[Yoav Weiss]

+Marcos for Mozilla's take on this.

I think that it'd be better to make this intent only about RQ hints and break "Alternate-Content-Length" into a separate intent.

Regarding RQ hints, I think that it'd be good to provide users with more control over the quality of their images, and RQ hints will give us that.

OTOH, leaving the values of the RQ hints wide-open, with no defined semantics will result in interoperability issues. I believe we should fix that before shipping.

Since, as pointed out, the RQ discussion is still rather new, we should be able to answer both "how do we unship it?" as well as "how do we change it in the future if we got it wrong?" before shipping.

[Chris Bentzel]

On Tue, May 12, 2015 at 5:42 AM Yoav Weiss <yo...@yoav.ws> wrote:

+Marcos for Mozilla's take on this.

I think that it'd be better to make this intent only about RQ hints and break "Alternate-Content-Length" into a separate intent.

+1

 

Regarding RQ hints, I think that it'd be good to provide users with more control over the quality of their images, and RQ hints will give us that.

OTOH, leaving the values of the RQ hints wide-open, with no defined semantics will result in interoperability issues. I believe we should fix that before shipping.

Since, as pointed out, the RQ discussion is still rather new, we should be able to answer both "how do we unship it?" as well as "how do we change it in the future if we got it wrong?" before shipping.

--
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%3DBEiMzVp0AcmTFbZYmThmDO95uwGozFWc8u4%2BdCBKgyQg3w%40mail.gmail.com.

[Håvard Molland]

On Tue, May 12, 2015 at 11:42 AM, Yoav Weiss <yo...@yoav.ws> wrote:

+Marcos for Mozilla's take on this.

Since, as pointed out, the RQ discussion is still rather new, we should be able to answer both "how do we unship it?" as well as "how do we change it in the future if we got it wrong?" before shipping.

 

Regarding how to unship, I don't think that is a problem if this is implemented in a such way that the client only sends the RQ header if it wants a different quality than the default.  This way, no page can be built to be dependent on receiving the RQ header.

Cheers,

Håvard

 

[Matt Welsh]

Hi Yoav,

Agreed on all points. While I don't mind breaking out Alternate-Content-Length into its own I2I, we're going to need to have that discussion anyway since I claim that RQ is a lot less useful without some way to convey compression benefit to the user agent. The only thing this might do for us is allow us to move ahead with RQ by itself even if we don't reach consensus on Alternate-Content-Length -- but that's not necessarily a good thing. Thoughts on this?

Happy to define whatever criteria people think make sense for deciding when to unship or change it. Is there a pattern from previous intents we can use?

Matt

[David Tapuska]

> - Alternate-Content-Length has the same meaning as the Content-Length header, which is supposed to represent the number of bytes "on the wire" after applying content-encodings like gzip. Your example ("Large deviation of bytes over the wire vs content length of response" for BMP with content-encoding: gzip) is not accurate.

I was more thinking of the typically deployed scenario where nginx in a front end server and it is a pass through to a back-end server; and the front end is configured to do gzip compression and turns the response into a gzipped chunked encoding. And the back-end would just return the alternate-content-length; but not know the server was doing gzip on it. Of course this is something that would need to be configured as the default gzip type for nginx is just to stream gzip text/html; not something like image/bmp. But I truly imagine gzipping image responses is probably low.

[Chris Bentzel]

On Tue, May 12, 2015 at 12:03 PM 'Matt Welsh' via net-dev <net...@chromium.org> wrote:

Hi Yoav,

Agreed on all points. While I don't mind breaking out Alternate-Content-Length into its own I2I, we're going to need to have that discussion anyway since I claim that RQ is a lot less useful without some way to convey compression benefit to the user agent. The only thing this might do for us is allow us to move ahead with RQ by itself even if we don't reach consensus on Alternate-Content-Length -- but that's not necessarily a good thing. Thoughts on this?

My rationale for breaking it out (or at least +1'ing) is that RQ could be useful without Alternate-Content-Length, and Alternate-Content-Length useful without RQ.

For example, an origin site could use the RQ signal as a heuristic to present a "lite" version of the site, where calculating Alternate-Content-Length may be very difficult to do since it transforms not just an individual resource but the overall page as well as subresources used.

Also, Alternate-Content-Length could be useful for Data Compression proxies (reverse or forward) to indicate savings even when ignoring the Resource Quality Client-Hints.

Happy to define whatever criteria people think make sense for deciding when to unship or change it. Is there a pattern from previous intents we can use?

Matt

On Tue, May 12, 2015 at 2:42 AM Yoav Weiss <yo...@yoav.ws> wrote:

+Marcos for Mozilla's take on this.

I think that it'd be better to make this intent only about RQ hints and break "Alternate-Content-Length" into a separate intent.

Regarding RQ hints, I think that it'd be good to provide users with more control over the quality of their images, and RQ hints will give us that.

OTOH, leaving the values of the RQ hints wide-open, with no defined semantics will result in interoperability issues. I believe we should fix that before shipping.

Since, as pointed out, the RQ discussion is still rather new, we should be able to answer both "how do we unship it?" as well as "how do we change it in the future if we got it wrong?" before shipping.

--
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/CAGz5krpKuvabmdyp6WeQ_eMknX2ALQz_VTG0dfw2AU4RVyZK9g%40mail.gmail.com.

[Matt Welsh]

Good points about decoupling them. Should I revise the RQ doc to remove references to that and do a separate I2I for the Alternate-Content-Length header? (Does it make sense to wait until we've converged on RQ first?)

Matt

[Ilya Grigorik]

On Tue, May 12, 2015 at 9:37 AM, Matt Welsh <m...@google.com> wrote:

Good points about decoupling them. Should I revise the RQ doc to remove references to that and do a separate I2I for the Alternate-Content-Length header? (Does it make sense to wait until we've converged on RQ first?)

FWIW, I think they're separate discussions and can proceed in parallel.

[Chris Bentzel]

+1

[Matt Welsh]

OK, will do.

For the present request then please ignore all references to Alternate-Content-Length (invoking Men In Black mind eraser...)

[PhistucK]

On Tue, May 12, 2015 at 1:17 AM, 'Matt Welsh' via net-dev <net...@chromium.org> wrote:

Whatever you are looking at probably does not reflect the full discussion we've had.

​I believe Ryan was looking at the chromestatus.com link you mentioned in the intent -

https://www.chromestatus.com/features/5504430086553600​

Which indeed shows everything orange (mixed to no signals).

☆PhistucK

[PhistucK]

On Tue, May 12, 2015 at 1:24 AM, 'Matt Welsh' via net-dev <net...@chromium.org> wrote:

At the same time there is little incentive for a server to lie about it. It's only intended to be informative to the user.

​Some large ad company puts a Alternate-Content-Length larger than Content-Length and the browser would have to show the numbers, which makes the feature (Chrome Data Saver, for example) or Chrome look bad ("hey, it used much more data, this sucks, disabling/uninstalling").

I assume you do intend to include such numbers (Alternate-Content-Length larger than Content-Length).

Yes, a stretch, but who knows.

☆PhistucK

[Matt Welsh]

Oh, I see. Ilya must have put that on the chromestatus dashboard - I have no idea how that's populated.

--

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/CABc02_%2B_otW-mwZOO4twx9%2B3AcoG9opTfnUJGs2wYrZ6BaqvJQ%40mail.gmail.com.

[PhistucK]

https://www.chromestatus.com/admin/features/edit/5504430086553600

The fields are manually populated. Perhaps this needs its own feature, with its own interoperability story.

I am not sure any chromium.org account can edit, but you can easily request edit access from the link at the footer of the page if you cannot access the edit page.

☆PhistucK

[David Tapuska]

How does caching work with this on the client; I see that our client cache supports "Vary"; but what about when the image isn't transformed but others on the page are? 

I presume that the chrome data saving mechanism could be turned on when on cellular technology but on wifi you may want no data savings. ie; if I disable chrome data savings; I should get high fidelity images even if I have items in my cache no? Or maybe pages elect not to send gradients in images (to get higher image compression) but would look funny when it is mixed with resources that are fetched with it on vs with it off? 

An extension to the Network Info API http://w3c.github.io/netinfo/ might actually be more useful to indicate data saver mode; then the client could just request different URIs.

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

[Ilya Grigorik]

On Tue, May 12, 2015 at 11:17 AM, PhistucK <phis...@gmail.com> wrote:

https://www.chromestatus.com/admin/features/edit/5504430086553600

The fields are manually populated. Perhaps this needs its own feature, with its own interoperability story.

Ah, good catch. Updated above link to cover RW and DPR. Created separate feature for RQ:

https://www.chromestatus.com/feature/5720139752275968

On Tue, May 12, 2015 at 11:31 AM, David Tapuska <dtap...@google.com> wrote:

How does caching work with this on the client; I see that our client cache supports "Vary"; but what about when the image isn't transformed but others on the page are? 

Each resource has its own caching policy (including Vary) so this is not an issue.

 

I presume that the chrome data saving mechanism could be turned on when on cellular technology but on wifi you may want no data savings. ie; if I disable chrome data savings; I should get high fidelity images even if I have items in my cache no? Or maybe pages elect not to send gradients in images (to get higher image compression) but would look funny when it is mixed with resources that are fetched with it on vs with it off? 

I think this is best deferred to the UA.. just as we have with responsive images.

 

An extension to the Network Info API http://w3c.github.io/netinfo/ might actually be more useful to indicate data saver mode; then the client could just request different URIs.

This is a separate discussion; one does not eliminate the need for the other - e.g. with NetInfo-only solution there is no way to know that the user has data savings enabled on first request.

ig

[PhistucK]

On Tue, May 12, 2015 at 9:43 PM, Ilya Grigorik <igri...@google.com> wrote:

Ah, good catch. Updated above link to cover RW and DPR. Created separate feature for RQ:

https://www.chromestatus.com/feature/5720139752275968

"Under Consideration" is not "Public support" by Microsoft. It is their default. It is either "No signals" or "Mixed signals" ("Not currently planned" is "No signals", "Mixed signals" or even "Negative signals").​ If you have public discussions that show "public support", you should link to them. Please, make sure the data accurately represents the actual views of others (with some backing)...

And the Firefox bug requires you to read the comments instead of linking to one of the comments that show the positive signal...

Some link for the web developer signal would also be nice, I cannot just count on your word. ;)

☆PhistucK

[Ilya Grigorik]

(side tracking here, apologies..)

On Tue, May 12, 2015 at 11:55 AM, PhistucK <phis...@gmail.com> wrote:

On Tue, May 12, 2015 at 9:43 PM, Ilya Grigorik <igri...@google.com> wrote:

Ah, good catch. Updated above link to cover RW and DPR. Created separate feature for RQ:

https://www.chromestatus.com/feature/5720139752275968

"Under Consideration" is not "Public support" by Microsoft. It is their default. It is either "No signals" or "Mixed signals" ("Not currently planned" is "No signals", "Mixed signals" or even "Negative signals").​ If you have public discussions that show "public support", you should link to them. Please, make sure the data accurately represents the actual views of others (with some backing)...

Fixed. 

And the Firefox bug requires you to read the comments instead of linking to one of the comments that show the positive signal...

Some link for the web developer signal would also be nice, I cannot just count on your word. ;)

Current dashboard doesn't allow us to provide a link for developer signals. That said, see the doc linked in the description:

https://docs.google.com/document/d/1SnRhnR_oWQ4Rivb7InJ9a_0T2k9CnuhNcMkd9xtLrKY/edit

p.s. if you have other feedback on RW/DPR, let's take it to: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/vOgv-TqefsA

[Ryan Sleevi]

On Tue, May 12, 2015 at 12:45 PM, 'Ilya Grigorik' via net-dev
<net...@chromium.org> wrote:
> (side tracking here, apologies..)

> Current dashboard doesn't allow us to provide a link for developer signals.
> That said, see the doc linked in the description:
> https://docs.google.com/document/d/1SnRhnR_oWQ4Rivb7InJ9a_0T2k9CnuhNcMkd9xtLrKY/edit

I don't think it's fair to generalize the comments on that doc to
being about RQ, from what I can tell.

>
> p.s. if you have other feedback on RW/DPR, let's take it to:
> https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/vOgv-TqefsA

As an aside, at some point, we need to figure out the right venue for
these discussions.

Blink-dev is a firehose I hope to not need to drink from. As it
relates to network-related, web-facing features, does it make sense to
cross-post? Is the argument that net-dev goes on BCC? blink-dev to
bcc?

As a forcing function, if this was on blink-dev, I wouldn't have
chimed in, or, if I had, I wouldn't have followed the discussion once
I was removed from the cc line. I suppose for those wanting to get a
feature through with no concerns, that's probably a good thing ;) but
it's at least worth highlighting as a potential loss of feedback.

[Alexey Baranov]

+ igrigorik@

 

 

12.05.2015, 21:44, "'Ilya Grigorik' via blink-dev" <blin...@chromium.org>:

On Tue, May 12, 2015 at 11:17 AM, PhistucK <phis...@gmail.com> wrote:

https://www.chromestatus.com/admin/features/edit/5504430086553600

The fields are manually populated. Perhaps this needs its own feature, with its own interoperability story.

 

Ah, good catch. Updated above link to cover RW and DPR. Created separate feature for RQ:

https://www.chromestatus.com/feature/5720139752275968

On Tue, May 12, 2015 at 11:31 AM, David Tapuska <dtap...@google.com> wrote:

How does caching work with this on the client; I see that our client cache supports "Vary"; but what about when the image isn't transformed but others on the page are? 

 

Each resource has its own caching policy (including Vary) so this is not an issue.

I guess the catch was that some image may not have been transformed to lower quality (it is too small (icons) or any other reason), while others were. In this case, after changing RQ, this image will be re-requested (Vary: RQ), but in reality it's the same resource.  

[Yoav Weiss]

On Tue, May 12, 2015 at 10:56 PM, Alexey Baranov <baran...@yandex-team.ru> wrote:

+ igrigorik@

 

 

12.05.2015, 21:44, "'Ilya Grigorik' via blink-dev" <blin...@chromium.org>:

On Tue, May 12, 2015 at 11:17 AM, PhistucK <phis...@gmail.com> wrote:

https://www.chromestatus.com/admin/features/edit/5504430086553600

The fields are manually populated. Perhaps this needs its own feature, with its own interoperability story.

 

Ah, good catch. Updated above link to cover RW and DPR. Created separate feature for RQ:

https://www.chromestatus.com/feature/5720139752275968

On Tue, May 12, 2015 at 11:31 AM, David Tapuska <dtap...@google.com> wrote:

How does caching work with this on the client; I see that our client cache supports "Vary"; but what about when the image isn't transformed but others on the page are? 

 

Each resource has its own caching policy (including Vary) so this is not an issue.

I guess the catch was that some image may not have been transformed to lower quality (it is too small (icons) or any other reason), while others were. In this case, after changing RQ, this image will be re-requested (Vary: RQ), but in reality it's the same resource.  

If the image wasn't modified according to the RQ signal, the server should not send a "Vary: RQ" header back, which means that the image will be cached regardless of the RQ request header, and won't be re-requested. 

[David Tapuska]

I was thinking the converse. That the first image requested isn't transformed because RQ isn't set; and Vary isn't applied and that resource is cached. But then if a subsequent fetch occurs when Vary is on; the website will then send resources that are varied because the RQ header is sent. I was assuming RQ isn't sent requests when it isn't enabled.

Is the answer to this that all servers that look for RQ should always return Vary?

dave.

[Ilya Grigorik]

On Tue, May 12, 2015 at 1:31 PM, Ryan Sleevi <rsl...@chromium.org> wrote:

On Tue, May 12, 2015 at 12:45 PM, 'Ilya Grigorik' via net-dev
<net...@chromium.org> wrote:
> (side tracking here, apologies..)
> Current dashboard doesn't allow us to provide a link for developer signals.
> That said, see the doc linked in the description:
> https://docs.google.com/document/d/1SnRhnR_oWQ4Rivb7InJ9a_0T2k9CnuhNcMkd9xtLrKY/edit

I don't think it's fair to generalize the comments on that doc to
being about RQ, from what I can tell.

Yes, apologies about the confusion, that doc is for RW & DPR.

[Philip Jägenstedt]

Is this intent blocked on feedback from the Blink API owners, or does
net-dev have its own launch process? It's listed under
http://bit.ly/blinkintents/ and I'm not sure what the next steps are.

[Kenji Baheux]

Sorry for the lack of updates.

Nat, myself and a few other folks want to better understand how RQ fits in the RAIL performance model narrative.  

Unfortunately, because of I/O and some additional hurdles, we couldn't setup a meeting with Matt until next week (June 1st).

[Elliott Sprehn]

Why isn't this Resource-Hints? It's very weird that this header is just two characters, but for example CORS uses Access-Control-...

It doesn't seem necessary to elide this down to two chars.

[Matt Welsh]

My understanding is that the brief header notation was chosen after discussion with mnot about headers for client hints. Ilya could comment further.

[Ilya Grigorik]

On Tue, Jun 9, 2015 at 3:29 PM, Elliott Sprehn <esp...@chromium.org> wrote:

Why isn't this Resource-Hints? It's very weird that this header is just two characters, but for example CORS uses Access-Control-...

We need to have separate headers for each hint to be Vary-compatible -- e.g. client sends multiple hints but server only uses one to select the response, if all the hints are sent in the same header than Vary'ing on it would create unnecessary fragmentation.

As far as names themselves are concerned, it comes down to a balance between saving bytes and user-friendliness. We're discussing expanding them [1], and for RQ in particular I think we might want to revisit the name to more closely reflect the "data saver is on" semantics.

[1] https://github.com/igrigorik/http-client-hints/issues/40

[Dimitri Glazkov]

Apologies for taking so long. Vacations, summer heat, dog-ate-homework, etc. We will get this resolved at the next API Owners meeting.

:DG<

[Ilya Grigorik]

Quick update.. After more discussion we've converged on a simplified proposal that specifically indicates user opt-in into a "reduced data usage" mode: https://github.com/igrigorik/http-client-hints/pull/55 - see "files changed" tab for spec definition.

If you have any feedback on above proposal please chime in on the Github pull.

We'll send out a new intent for this simplified proposal.