Re: p6: Returning the freshest response

Mark Nottingham <mnot@mnot.net> Wed, 03 April 2013 04:35 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 00AAC21E8041 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 2 Apr 2013 21:35:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LhDhorHvDmlw for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 2 Apr 2013 21:35:50 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 416D221F86CA for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 2 Apr 2013 21:35:46 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UNFNo-0004ax-2Z for ietf-http-wg-dist@listhub.w3.org; Wed, 03 Apr 2013 04:33:12 +0000
Resent-Date: Wed, 03 Apr 2013 04:33:12 +0000
Resent-Message-Id: <E1UNFNo-0004ax-2Z@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <mnot@mnot.net>) id 1UNFNm-0004a9-9I for ietf-http-wg@listhub.w3.org; Wed, 03 Apr 2013 04:33:10 +0000
Received: from mxout-07.mxes.net ([216.86.168.182]) by maggie.w3.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <mnot@mnot.net>) id 1UNFNj-00026x-Di for ietf-http-wg@w3.org; Wed, 03 Apr 2013 04:33:10 +0000
Received: from [192.168.1.80] (unknown [118.209.42.8]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 4680D22E255; Wed, 3 Apr 2013 00:32:43 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <51578395.6070800@treenet.co.nz>
Date: Wed, 3 Apr 2013 15:32:39 +1100
Cc: ietf-http-wg@w3.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <F3BC48ED-ACF6-4CA4-A0EE-089BBCD98069@mnot.net>
References: <E56A5FA7-555D-4283-95A1-FD0030D4616A@mnot.net> <CABkgnnXbDfXN1KA-AfHcW=macw44hK346z0UuYMZYx8OXBZv4g@mail.gmail.com> <51578395.6070800@treenet.co.nz>
To: Amos Jeffries <squid3@treenet.co.nz>
X-Mailer: Apple Mail (2.1503)
Received-SPF: pass client-ip=216.86.168.182; envelope-from=mnot@mnot.net; helo=mxout-07.mxes.net
X-W3C-Hub-Spam-Status: No, score=-3.4
X-W3C-Hub-Spam-Report: AWL=-3.364, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001
X-W3C-Scan-Sig: maggie.w3.org 1UNFNj-00026x-Di 91e8494db68c7f80efd2a2db0d92b3ef
X-Original-To: ietf-http-wg@w3.org
Subject: Re: p6: Returning the freshest response
Archived-At: <http://www.w3.org/mid/F3BC48ED-ACF6-4CA4-A0EE-089BBCD98069@mnot.net>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17194
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 31/03/2013, at 11:30 AM, Amos Jeffries <squid3@treenet.co.nz> wrote:

> Perhapse this is a bit better?
> 
> "
> 
> If multiple selected responses are available, the cache will need to choose one to use. When a selecting header has a known mechanism for doing so (e.g., qvalues on Accept and similar request headers), that mechanism SHOULD be used to eliminate unwanted responses; of the remainder, the most recent response (as determined by the Date header field) is used, as per Section 4.
> 
> "
> 
> Making it clear that Date mechanism still applies, but only after the negotiation filtering has been done. AFAIK that is how it always gets done in practice anyway.

I'm OK with your intent, but upgrading the MAY to a SHOULD is going to make implementations non-conformant. 


--
Mark Nottingham   http://www.mnot.net/