Re: #428 Accept-Language ordering for identical qvalues

"Adrien W. de Croy" <adrien@qbik.com> Tue, 22 January 2013 09:33 UTC

Return-Path: <ietf-http-wg-request@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A8CC21F881C for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 22 Jan 2013 01:33:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.199
X-Spam-Level:
X-Spam-Status: No, score=-9.199 tagged_above=-999 required=5 tests=[AWL=1.399, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4RtVgSHiJk6L for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 22 Jan 2013 01:33:12 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 095DD21F8818 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 22 Jan 2013 01:33:11 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1TxaD0-000864-7g for ietf-http-wg-dist@listhub.w3.org; Tue, 22 Jan 2013 09:31:58 +0000
Resent-Date: Tue, 22 Jan 2013 09:31:58 +0000
Resent-Message-Id: <E1TxaD0-000864-7g@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <adrien@qbik.com>) id 1TxaCu-00085L-9p for ietf-http-wg@listhub.w3.org; Tue, 22 Jan 2013 09:31:52 +0000
Received: from smtp.qbik.com ([210.55.214.35]) by lisa.w3.org with esmtp (Exim 4.72) (envelope-from <adrien@qbik.com>) id 1TxaCs-0004lu-5s for ietf-http-wg@w3.org; Tue, 22 Jan 2013 09:31:52 +0000
Received: From [192.168.0.10] (unverified [192.168.0.10]) by SMTP Server [192.168.0.1] (WinGate SMTP Receiver v7.5.0 (Build 3481)) with SMTP id <0019476958@smtp.qbik.com>; Tue, 22 Jan 2013 22:33:00 +1300
From: "Adrien W. de Croy" <adrien@qbik.com>
To: "James M Snell" <jasnell@gmail.com>, "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>
Date: Tue, 22 Jan 2013 09:30:54 +0000
Content-Type: multipart/alternative; boundary="------=_MBDF5E1E96-AFFA-40A7-81E1-0403E36B337F"
In-Reply-To: <CABP7RbdECWmkcknKVaq_LPUpsEsSiKOdJ-au2aw89nQX+bKdMQ@mail.gmail.com>
Message-Id: <emd05c9b5b-e16a-43b5-aabc-a744298d5527@bombed>
Mime-Version: 1.0
Reply-To: "Adrien W. de Croy" <adrien@qbik.com>
User-Agent: eM_Client/5.0.17263.0
Received-SPF: pass client-ip=210.55.214.35; envelope-from=adrien@qbik.com; helo=smtp.qbik.com
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-3.449, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1TxaCs-0004lu-5s c0a727c70d09d120e0b850e6efd4b6d0
X-Original-To: ietf-http-wg@w3.org
Subject: Re: #428 Accept-Language ordering for identical qvalues
Archived-At: <http://www.w3.org/mid/emd05c9b5b-e16a-43b5-aabc-a744298d5527@bombed>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/16099
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

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>om>; "Julian F. Reschke" 
<julian.reschke@gmx.de>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/
>>
>>
>>
>>
>