This change introduces use of a new HTTP response header "Alternate-Content-Length" that allows an origin site or proxy to report on the size of an "alternate" response. For example, in the case of a compressing proxy, Alternate-Content-Length would indicate the size of the uncompressed response. Alternate-Content-Length is intended as a purely informational signal to the user-agent about the volume of data that would have been transferred had content transformation not been applied.
In the case of requests made with the RQ client-hints header, Alternate-Content-Length is intended to represent the number of bytes for the response had no RQ header been used.
Additional background (covering both RQ and Alternate-Content-Length): https://docs.google.com/document/d/1YAqkbf6VQhtnrHd7z1Jrpb5WtObUZL8gsU6v42qHlWQ/edit
Websites and proxies frequently employ content transformation to reduce the number of bytes for responses, e.g., through image or video transcoding, gzipping, or other compression schemes. However, there is no standard way for a proxy or site to indicate to the user-agent the volume of data that is saved by these transformations. The Chrome Data Saver proxy uses the X-Original-Content-Length header for this purpose. However, transparent proxies or websites that respect the proposed RQ have no mechanism to inform the user-agent of compression savings. Being able to convey this information to the user-agent allows the user interface to directly indicate the savings and motivate the use for byte savings on the web.
Origins and proxies are not required to support the Alternate-Content-Length header.
Ongoing technical constraints
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
OWP launch tracking bug?
Link to entry on the feature dashboard
Requesting approval to ship?
Is there any use case for this outside of private proxies?
Is this a per-hop header? What are the semantics when multiple proxies are involved? What transformations are there?
The use case here suggests it is solely for browser UI/statistics, and has no value/use outside of that. Is that a fair statement? Why or why not?
All good questions, and I agree with Jonny's responses. Also, mobile carriers frequently perform content transformations on their own and would like to be able to inform end user devices of those savings - so it is not limited to browser-based proxies like Opera Turbo or Chrome Data Saver.I believe that Alternate-Content-Length, if present, should be preserved by intermediate proxies.I think Ryan's assertion that this is solely for UI and statistics is right.To answer Jonny's questions:- Alternate-Content-Length should be accompanied by 'RQ: low' in the response.
On May 14, 2015 8:51 AM, "'Matt Welsh' via net-dev" <net...@chromium.org> wrote:
> The main value for the header outside of the vendor-specific proxies is to give sites the opportunity to report on the data savings they granted the user when the user requested an 'RQ: low' resource. It is also useful for transparent proxies to report their savings irrespective of whether the request carried an 'RQ: low' value (since proxies may do compression without the user requesting it).
Still need to define the interaction between these two (when both a proxy and a server send it)
I definitely think a spec is necessary for further evaluation here, at least to have a meaningful discussion of the myriad edge cases and interpretations. Even if we say it is just for browser UI, if server A assumes it to mean X and server B assumes it to mean Y, then we have a real compatibility/interoperability issue.
> You are absolutely correct that there is no way to directly verify the truth of the reported A-C-L value, and many "abuse" cases are possible (spoofing abnormally high A-C-Ls, etc. as you point out). However, given that the purpose is purely informational, I believe the value in providing a best-effort mechanism allowing honest players to report this data truthfully outweighs the downside to its potential misuse. There are also some mitigations: User agents could decide not to trust A-C-L values from certain sources, for example.
> I would personally rather have A-C-L be in the spec and something that we encourage sites and browser vendors to support rather than maintain the current 'dark pattern' of unofficial headers to convey this information.
Well, there's always the option of not munging the stream and delivering it out of bad, via a separate API, etc. Just making sure all options (even the undesirable ones) are on the table. Plenty of proxy solutions in the past have accomplished this without the header.
> I'm not sure what case Jonny is thinking about but I believe that A-C-L has no value other than for browser UI.
Thanks for confirming - at least that helps mitigate some of the compatibility risks for now. Although somewhat weird to add overhead to a compressing proxy ;)
Right, I agree. There *is* a spec - it's just underspecified, although I see now that it hasn't yet been committed to the Client Hints spec.