W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2013

Re: #428 Accept-Language ordering for identical qvalues

From: Roy T. Fielding <fielding@gbiv.com>
Date: Mon, 21 Jan 2013 00:37:12 -0800
Cc: "Julian F. Reschke" <julian.reschke@gmx.de>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <6E9D9BB9-A5F5-417A-A640-AF03AFCC6496@gbiv.com>
To: Mark Nottingham <mnot@mnot.net>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 21 January 2013 08:37:40 GMT