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?
Link to entry on the feature dashboard
https://www.chromestatus.com/features/5504430086553600
Requesting approval to ship?
Yes
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
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).
--
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.
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.
+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/CACj%3DBEiMzVp0AcmTFbZYmThmDO95uwGozFWc8u4%2BdCBKgyQg3w%40mail.gmail.com.
+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.
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?MattOn 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.
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?)
Whatever you are looking at probably does not reflect the full discussion we've had.
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.
--
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.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
The fields are manually populated. Perhaps this needs its own feature, with its own interoperability story.
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.
Ah, good catch. Updated above link to cover RW and DPR. Created separate feature for RQ:
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:"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. ;)
On Tue, May 12, 2015 at 11:17 AM, PhistucK <phis...@gmail.com> wrote: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: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.
+ 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: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: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.
Why isn't this Resource-Hints? It's very weird that this header is just two characters, but for example CORS uses Access-Control-...