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