Re: #428 Accept-Language ordering for identical qvalues

Amos Jeffries <squid3@treenet.co.nz> Tue, 22 January 2013 10:26 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 D52C521F8901 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 22 Jan 2013 02:26:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.024
X-Spam-Level:
X-Spam-Status: No, score=-9.024 tagged_above=-999 required=5 tests=[AWL=0.375, 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 FpGmh6med6Wc for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 22 Jan 2013 02:26:22 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 521A421F8800 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 22 Jan 2013 02:26:22 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1Txb2l-00011s-5x for ietf-http-wg-dist@listhub.w3.org; Tue, 22 Jan 2013 10:25:27 +0000
Resent-Date: Tue, 22 Jan 2013 10:25:27 +0000
Resent-Message-Id: <E1Txb2l-00011s-5x@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <squid3@treenet.co.nz>) id 1Txb2e-00010e-JO for ietf-http-wg@listhub.w3.org; Tue, 22 Jan 2013 10:25:20 +0000
Received: from ip-58-28-153-233.static-xdsl.xnet.co.nz ([58.28.153.233] helo=treenet.co.nz) by lisa.w3.org with esmtp (Exim 4.72) (envelope-from <squid3@treenet.co.nz>) id 1Txb2d-0006nE-Ov for ietf-http-wg@w3.org; Tue, 22 Jan 2013 10:25:20 +0000
Received: from [192.168.1.109] (unknown [14.1.64.4]) by treenet.co.nz (Postfix) with ESMTP id 79099E72D6 for <ietf-http-wg@w3.org>; Tue, 22 Jan 2013 23:24:56 +1300 (NZDT)
Message-ID: <50FE68F4.8080005@treenet.co.nz>
Date: Tue, 22 Jan 2013 23:24:52 +1300
From: Amos Jeffries <squid3@treenet.co.nz>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: ietf-http-wg@w3.org
References: <emd05c9b5b-e16a-43b5-aabc-a744298d5527@bombed>
In-Reply-To: <emd05c9b5b-e16a-43b5-aabc-a744298d5527@bombed>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass client-ip=58.28.153.233; envelope-from=squid3@treenet.co.nz; helo=treenet.co.nz
X-W3C-Hub-Spam-Status: No, score=-3.2
X-W3C-Hub-Spam-Report: AWL=-3.184, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1Txb2d-0006nE-Ov dd431d9a17fb64487e0044d0d5173e0d
X-Original-To: ietf-http-wg@w3.org
Subject: Re: #428 Accept-Language ordering for identical qvalues
Archived-At: <http://www.w3.org/mid/50FE68F4.8080005@treenet.co.nz>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/16102
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>

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