Re: #428 Accept-Language ordering for identical qvalues

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.

....Roy

Received on Monday, 21 January 2013 08:37:38 UTC