Re: #428 Accept-Language ordering for identical qvalues

"Adrien W. de Croy" <adrien@qbik.com> Tue, 22 January 2013 11:16 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 5715A21F87CE for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 22 Jan 2013 03:16:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.038
X-Spam-Level:
X-Spam-Status: No, score=-9.038 tagged_above=-999 required=5 tests=[AWL=0.361, BAYES_00=-2.599, J_CHICKENPOX_47=0.6, J_CHICKENPOX_74=0.6, 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 VvFgEsu2X0Pn for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 22 Jan 2013 03:16:19 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 8F85621F87C8 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 22 Jan 2013 03:16:19 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1TxboM-0005P5-Hg for ietf-http-wg-dist@listhub.w3.org; Tue, 22 Jan 2013 11:14:38 +0000
Resent-Date: Tue, 22 Jan 2013 11:14:38 +0000
Resent-Message-Id: <E1TxboM-0005P5-Hg@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 1TxboF-0005Ne-Rt for ietf-http-wg@listhub.w3.org; Tue, 22 Jan 2013 11:14:31 +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 1TxboE-0000Kw-P5 for ietf-http-wg@w3.org; Tue, 22 Jan 2013 11:14:31 +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 <0019477034@smtp.qbik.com>; Wed, 23 Jan 2013 00:15:44 +1300
From: "Adrien W. de Croy" <adrien@qbik.com>
To: "Amos Jeffries" <squid3@treenet.co.nz>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Date: Tue, 22 Jan 2013 11:13:37 +0000
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; format=flowed; charset=utf-8
In-Reply-To: <50FE68F4.8080005@treenet.co.nz>
Message-Id: <emd9a7e252-b68d-47ac-991e-6dbc843de358@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.2
X-W3C-Hub-Spam-Report: AWL=-3.211, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1TxboE-0000Kw-P5 7655bace7c4e39c8d47b2a64702fb80b
X-Original-To: ietf-http-wg@w3.org
Subject: Re: #428 Accept-Language ordering for identical qvalues
Archived-At: <http://www.w3.org/mid/emd9a7e252-b68d-47ac-991e-6dbc843de358@bombed>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/16105
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>

13.6 para 3 & 4

"When the cache receives a subsequent request whose Request-URI
specifies one or more cache entries including a Vary header field,
the cache MUST NOT use such a cache entry to construct a response to
the new request unless all of the selecting request-headers present
in the new request match the corresponding stored request-headers in
the original request.

The selecting request-headers from two requests are defined to match
if and only if the selecting request-headers in the first request can
be transformed to the selecting request-headers in the second request
by adding or removing linear white space (LWS) at places where this
is allowed by the corresponding BNF, and/or combining multiple
message-header fields with the same field name following the rules
about message headers in section 4.2. "

Cheers

Adrien

------ Original Message ------
From: "Amos Jeffries" <squid3@treenet.co.nz>
To: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Sent: 22/01/2013 11:24:52 p.m.
Subject: Re: #428 Accept-Language ordering for identical qvalues
>On 22/01/2013 10:30 p.m., Adrien W. de Croy wrote:
>>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'm interested in where that "MUST NOT" comes from. My understanding 
>was that in the cache role we could take the Content-Encoding header on 
>the stored reply as the variant key on the vary response to match 
>against the new client Accept-Encoding entries and serve up the HIT if 
>we really wanted to.
>
>>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.
>>
>
>But this is a case of a metric where the browser agent *can* usually 
>determine ordering automatically.
>
>For example; deflate, gzip, and friends have different CPU consumption 
>and bandwidth saving profiles. The browser can get access to the 
>clients own CPU and uplink properties to determine whether it needs to 
>proritize deflate,gzip or gzip,deflate. Having both indicated shows 
>that either format response is acceptible, but the more responses this 
>client gets in the first-listed entry the better the user experience.
>
>Amos
>