Re: #428 Accept-Language ordering for identical qvalues

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

Adrien


------ Original Message ------
From: "James M Snell" <jasnell@gmail.com>
To: "Mark Nottingham" <mnot@mnot.net>
Cc: "Roy T. Fielding" <fielding@gbiv.com>; "Julian F. Reschke" 
<julian.reschke@gmx.de>; "HTTP Working Group" <ietf-http-wg@w3.org>
Sent: 22/01/2013 6:58:35 p.m.
Subject: Re: #428 Accept-Language ordering for identical qvalues
>+1 on this... in the end, it's far better to have all the similar 
>things acting in the same way. Not only does that help developers, it's 
>going to help us make improvements in 2.0 and beyond.
>
>
>On Mon, Jan 21, 2013 at 2:41 AM, Mark Nottingham <mnot@mnot.net> wrote:
>>
>>On 21/01/2013, at 7:37 PM, Roy T. Fielding <fielding@gbiv.com> wrote:
>>
>> > On Jan 20, 2013, at 1:51 PM, Mark Nottingham wrote:
>> >> On 20/01/2013, at 11:52 PM, Roy T. Fielding <fielding@gbiv.com> 
>>wrote:
>> >>
>> >>> On Jan 19, 2013, at 6:34 PM, Mark Nottingham wrote:
>> >>>
>> >>>> Julian et al,
>> >>>>
>> >>>> I think the important bit here is the context that we're talking 
>>about the semantics of an expressed preference -- which can be freely 
>>ignored, or selectively applied, without affecting conformance. The 
>>important thing is that the preference itself have clear semantics, 
>>which I think Roy's change does (especially in concert with changes 
>>elsewhere).
>> >>>>
>> >>>> As such, I think the relevant question is whether this is 
>>specific to A-L, or all A-* that take qvalues. Roy, thoughts?
>> >>>
>> >>> I am pretty sure it is specific to languages.  Accept has never 
>>been
>> >>> treated as an ordered list, Accept-Encoding was originally 
>>designed
>> >>> to prefer the smallest representation (changing that to qvalues 
>>was
>> >>> unfortunate), and Accept-Charset is almost deprecated at this 
>>point.
>> >>
>> >>
>> >> So, wouldn't the same arguments (minus the implementation status) 
>>apply to Accept?
>> >>
>> >> I.e., if it's just a preference, and the server is free to choose 
>>among the preferences anyway (or even ignore them), why *not* say 
>>Accept is ordered?
>> >
>> > I don't see any value in that given the lack of users setting the
>> > values for Accept directly (outside of command-line tool usage)
>> > and no assumption among UAs that Accept is ordered.
>> >
>> > Apache httpd resolves ties in type negotiation using the
>> > internal ordering of representation variants.  That is unlike
>> > languages, for which the code deliberately checks the order received
>> > in Accept-Language for resolving ties.
>> >
>> > Regarding proactive negotiation in HTTP/2, I'll note that Waka
>> > strips all negotiation fields.  I find the entire feature revolting,
>> > from every architectural perspective, and would take the opportunity
>> > of 2.x to remove it entirely.
>>
>>
>>The value is that Accept-* headers all use qvalues the same way, which 
>>is much less confusing for pretty much everybody, and paves the way 
>>for a potentially simpler approach in 2.0 (your feelings about having 
>>proactive negotiation at all noted).
>>
>>Again, implementations are free to ignore it -- this is merely the 
>>semantics of the preference, not constraints on how it's followed.
>>
>>
>>--
>>Mark Nottingham   http://www.mnot.net/
>>
>>
>>
>>
>