Re: #428 Accept-Language ordering for identical qvalues

[Amos Jeffries <[e-mail]>]

On 22/01/2013 10:30 p.m., Adrien W. de Croy wrote:
> Just wondering if there is anything to be discussed about Accept-Encoding.
> There are some cases where it can cause issues for a cache.
> for example
> GET /something HTTP/1.1
> Host: somewhere.com
> Accept-Encoding: gzip, deflate
> 200 OK HTTP/1.1
> Content-Encoding: gzip
> Cache-Control: max-age=2000000
> Vary: Accept-Encoding
> GET /something HTTP/1.1
> Host: somewhere.com
> Accept-Encoding: deflate, gzip
> cache MUST NOT select 1st response due to difference in 
> Accept-Encoding header between requests.  Even though there's arguably 
> no semantic difference.

I'm interested in where that "MUST NOT" comes from. My understanding was 
that in the cache role we could take the Content-Encoding header on the 
stored reply as the variant key on the vary response to match against 
the new client Accept-Encoding entries and serve up the HIT if we really 
wanted to.

> I've never seen a q value on Accept-Encoding, and the spec talks 
> about transforming headers as part of matching, but it only allows 
> adding / removal of LWS and combining multiples. Not re-ordering.
> I know there's the pathological case about something returning the 
> headers of the request, but it seems like a big price to pay for this.
> Maybe all browser vendors should always order Accept-Encoding tokens 
> in the same order.
>

But this is a case of a metric where the browser agent *can* usually 
determine ordering automatically.

For example; deflate, gzip, and friends have different CPU consumption 
and bandwidth saving profiles. The browser can get access to the clients 
own CPU and uplink properties to determine whether it needs to proritize 
deflate,gzip or gzip,deflate. Having both indicated shows that either 
format response is acceptible, but the more responses this client gets 
in the first-listed entry the better the user experience.

Amos