Intent to Implement and Ship: Alternate-Content-Length

[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 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

Motivation

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.

Compatibility risk

Origins and proxies are not required to support the Alternate-Content-Length 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]

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?

[Jonny Rein Eriksen]

On 12.05.2015 20:02, Ryan Sleevi wrote:
>
> Is there any use case for this outside of private proxies?
>

I assume with private proxies you mean compression proxies such as
Chrome Compression proxies and Opera Turbo proxies.

The main intention with RQ:low is to indicate to content servers that we
are requesting content on behalf of a user that uses a costly and/or bw
limited connection. Since the use of secure connections is rising and
these bypass our compression proxies it means that compression is being
used less. So to help users in compression mode get some of the same
benefits over secure connections we would like to see CH RQ:low support
also where proxies are not used.

In addition to using RQ:low for secure connections we can also use it
for the requests from the compression proxies to reduce the work these
have to do.

Alternate-Content-Length becomes a tool to see how effective original
content servers are at saving data for a user when RQ:low is used. For
end users it helps seeing how effective the bw saving mode is.

Apps can use the same headers to operate in a bw saving mode.

Other browsers without compression proxies of their own can still
support bw saving once content servers support RQ:low.

> Is this a per-hop header?
>

End to End.

>
> What are the semantics when multiple proxies are involved?
>

Understand the Vary RQ:low response to only serve cached responses based
on matching request headers?

If doing further optimizations the original Alternate-Content-Length
header should be kept?
>
> What transformations are there?
>
Not sure?

>
> 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?
>

For the original content server it is an indication as to how well the
site will work in a bw saving mode.

My contribution to the questions:

What should happen if Alternate-Content-Length is:
- Sent in a response without RQ:low being in the request?
- Being 100x larger or smaller than Content-Length?
- Sent without Vary header?

Jonny

[Matt Welsh]

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. Note that the request may not have an associated RQ header, for example, in the case of a transparent proxy performing content modification without the user's requesting it to do so.

  - I don't see any arbitrary restrictions on the value of Alternate-Content-Length; browsers may wish to ignore values they deem to be nonsensical.

  - Vary should apply to RQ, not to Alternate-Content-Length.

(Do these clarifications belong in the spec, in the associated doc, somewhere else?)

[Yoav Weiss]

On Wed, May 13, 2015 at 5:56 PM, Matt Welsh <m...@google.com> wrote:

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.

Why? We want to make RQ a response header as well as a request header?

[Ryan Sleevi]

On Wed, May 13, 2015 at 4:03 AM, Jonny Rein Eriksen <jon...@opera.com> wrote:
> I assume with private proxies you mean compression proxies such as Chrome
> Compression proxies and Opera Turbo proxies.

Yes. Specifically, what value or use case is there for this header
outside of vendor-specific solutions? Your response below still didn't
give me any insight into whether this has any value outside of those
(and I'll explain why I think the server-sent/RQ case is
problematic/bogus below)

> The main intention with RQ:low is to indicate to content servers that we are
> requesting content on behalf of a user that uses a costly and/or bw limited
> connection. Since the use of secure connections is rising and these bypass
> our compression proxies it means that compression is being used less. So to
> help users in compression mode get some of the same benefits over secure
> connections we would like to see CH RQ:low support also where proxies are
> not used.
>
> In addition to using RQ:low for secure connections we can also use it for
> the requests from the compression proxies to reduce the work these have to
> do.

Separate header, separate discussion. I understand the desire for the
RQ header, although I think it's problematic in its own rights.

> Alternate-Content-Length becomes a tool to see how effective original
> content servers are at saving data for a user when RQ:low is used. For end
> users it helps seeing how effective the bw saving mode is.
>
> Apps can use the same headers to operate in a bw saving mode.

Well, no, an app doesn't use Alt-Content-Length to operate in a B/W
saving mode, it just offers useful metrics.

>> Is this a per-hop header?
>>
> End to End.

So this makes less sense to me.

What happens if a server sends an Alt-Content-Length (for example,
because it GZip'd a response), and then the compressing proxy happens
to un-gzip the images and then transform them. What is the true
Alt-Content-Length? How does this get transformed?

This is where specs help ;)

> If doing further optimizations the original Alternate-Content-Length header
> should be kept?

See above

> For the original content server it is an indication as to how well the site
> will work in a bw saving mode.

Right, does this have any functional value for a browser outside of
UI? That's my core question ;)

>
> My contribution to the questions:
>
> What should happen if Alternate-Content-Length is:
> - Sent in a response without RQ:low being in the request?
> - Being 100x larger or smaller than Content-Length?
> - Sent without Vary header?

I also have questions about how well you trust the A-C-L header. It's
one thing if you're getting this information from a trusted proxy,
which is all well and good, but it's another thing if you're getting
it from an end-server.

For example, let's say example.com wanted to collude with Data Saving
Proxy Vendor A. For users whose User-Agent is DSPV-A, they send the
A-C-L at something laughable, like 4GB. For User-Agent DSPV-B, they
send the A-C-L equivalent to the C-L. If it is for UI, this now has
the effect of making it look like DSPV-A saves users substantially
more bandwidth than DSPV-B - even if it's the same resource.

Worse, there's little way to objectively quantify this, for a variety
of reasons, and so you end up with stats gamification. For that
matter, assuming the user has a choice between DSPV-A and DSPV-B, A
could just lie about how much it is saving users to make B look bad.

So I'm still having trouble with whether or not this header actually
makes sense, independent of the fact that some people have already
deployed it ;)

[Matt Welsh]

Ryan,

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).

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.

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.

Matt

[Ryan Sleevi]

On May 14, 2015 8:51 AM, "'Matt Welsh' via net-dev" <net...@chromium.org> wrote:
>
> Ryan,
>
> 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 ;)

[Matt Welsh]

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.

https://github.com/igrigorik/http-client-hints/commit/1df20def61eb42b2adf8e74778eaf6a6823ddefe

We'll go back and revise this with your feedback and come back.

From our analysis of the Chrome proxy data, the overhead of the additional header (especially with HTTP/2 header compression) is a tiny fraction of the total bytes.

[Ryan Sleevi]

On Thu, May 14, 2015 at 9:20 AM, Matt Welsh <m...@google.com> wrote:

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.

Not only is it under-specified, it relies on 3 year old, expired I-Ds as a way to mitigate some of the concerns ( http://igrigorik.github.io/http-client-hints/#I-D.fielding-http-key ). That's... not quite desirable... at least with respect to establishing maturity of the spec ;)

[Jonny Rein Eriksen]

On 14.05.2015 17:51, Matt Welsh wrote:
>
> 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.
>
> Matt

Matt,

It might be far fetched, but I was thinking that the compression proxies
could use A-C-L as input in deciding whether further processing would be
required.

Jonny

[Philip Jägenstedt]

Like with "RQ client hints header" I'm not sure who's responsibility
it is to move this along.

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

[Matt Welsh]

Philip,

Thanks for the ping. It's my responsibility to move this along, and I'm meeting with various folks internally to resolve some questions about this soon. The next step here is to revise the spec for the Alternate-Content-Length header to be more precise and address the questions Ryan Sleevi asked; that's on me but I haven't yet gotten around to it. (Ilya, any interest?)

Matt

[Philip Jägenstedt]

Thanks Matt, just wanted to check that it wasn't blocked on Blink API owners feedback. Given that this is a new HTTP header, will there be any Blink-side changes? I would have guessed that this is mostly a question for net/ in Chromium.

[Peter Kasting]

On Tue, May 12, 2015 at 10:12 AM, 'Matt Welsh' via blink-dev <blin...@chromium.org> wrote:

The Chrome Data Saver proxy uses the X-Original-Content-Length header for this purpose.

The word "original" here seems much clearer than "alternate" in the proposal.  At the risk of bikeshedding, if there a strong reason to prefer the phrase "alternate content length"?  It seems somewhat meaningless in the abstract.

PK 

[Chris Bentzel]

This will likely be a net/ only impact in terms of code (actually, I expect it to sit a bit outside the net/ stack - but it likely won't extend into Blink).

However, externally visible networking changes still will be following the Blink feature process, even if the code base is slightly different.