Re: p6: Returning the freshest response
Ken Murchison <murch@andrew.cmu.edu> Fri, 29 March 2013 15:25 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 7499521F93FF for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 29 Mar 2013 08:25:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level:
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 qMhIZBiJdFAv for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 29 Mar 2013 08:25:34 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 574D121F93CE for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 29 Mar 2013 08:25:34 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1ULbA2-0000xG-Uy for ietf-http-wg-dist@listhub.w3.org; Fri, 29 Mar 2013 15:24:10 +0000
Resent-Date: Fri, 29 Mar 2013 15:24:10 +0000
Resent-Message-Id: <E1ULbA2-0000xG-Uy@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <murch@andrew.cmu.edu>) id 1ULb9p-0000uy-U8 for ietf-http-wg@listhub.w3.org; Fri, 29 Mar 2013 15:23:57 +0000
Received: from smtp.andrew.cmu.edu ([128.2.11.95]) by lisa.w3.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <murch@andrew.cmu.edu>) id 1ULb9o-00019I-JT for ietf-http-wg@w3.org; Fri, 29 Mar 2013 15:23:57 +0000
Received: from [192.168.137.101] (cpe-76-180-197-142.buffalo.res.rr.com [76.180.197.142]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.14.4/8.14.4) with ESMTP id r2TFNTOE004545 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <ietf-http-wg@w3.org>; Fri, 29 Mar 2013 11:23:30 -0400
Message-ID: <5155B23A.2050002@andrew.cmu.edu>
Date: Fri, 29 Mar 2013 11:24:42 -0400
From: Ken Murchison <murch@andrew.cmu.edu>
Organization: Carnegie Mellon University
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: ietf-http-wg@w3.org
References: <E56A5FA7-555D-4283-95A1-FD0030D4616A@mnot.net>
In-Reply-To: <E56A5FA7-555D-4283-95A1-FD0030D4616A@mnot.net>
Content-Type: multipart/alternative; boundary="------------060105040004080309000000"
X-PMX-Version: 5.5.9.388399, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.5.19.222118
X-SMTP-Spam-Clean: 8% ( HTML_NO_HTTP 0.1, SUPERLONG_LINE 0.05, BODYTEXTH_SIZE_10000_LESS 0, RDNS_GENERIC_POOLED 0, RDNS_POOLED 0, RDNS_RESIDENTIAL 0, RDNS_SUSP 0, RDNS_SUSP_GENERIC 0, RDNS_SUSP_SPECIFIC 0, __ANY_URI 0, __BAT_BOUNDARY 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CP_MEDIA_BODY 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __CTYPE_MULTIPART_ALT 0, __HAS_HTML 0, __HAS_MSGID 0, __MAILTO_WITH_SUBJECT 0, __MIME_HTML 0, __MIME_VERSION 0, __MOZILLA_MSGID 0, __RDNS_POOLED_2 0, __SANE_MSGID 0, __STOCK_PHRASE_7 0, __TAG_EXISTS_HTML 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __URI_NO_PATH 0, __URI_NO_WWW 0, __URI_NS , __USER_AGENT 0)
X-SMTP-Spam-Score: 8%
X-Scanned-By: MIMEDefang 2.60 on 128.2.11.95
Received-SPF: none client-ip=128.2.11.95; envelope-from=murch@andrew.cmu.edu; helo=smtp.andrew.cmu.edu
X-W3C-Hub-Spam-Status: No, score=-5.3
X-W3C-Hub-Spam-Report: AWL=-1.649, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.303
X-W3C-Scan-Sig: lisa.w3.org 1ULb9o-00019I-JT d3c50f06390aeaebd018cc88023a2e00
X-Original-To: ietf-http-wg@w3.org
Subject: Re: p6: Returning the freshest response
Archived-At: <http://www.w3.org/mid/5155B23A.2050002@andrew.cmu.edu>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17171
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 28 March 2013 23:10, Mark Nottingham <mnot@mnot.net <mailto:mnot@mnot.net?Subject=Re%3A%20p6%3A%20Returning%20the%20freshest%20response&In-Reply-To=%253CCAF6rxg%3D96siQxgUUGwizQJYQ2XKyr1tdxj1URQWBjgWnS45WVw%40mail.gmail.com%253E&References=%253CCAF6rxg%3D96siQxgUUGwizQJYQ2XKyr1tdxj1URQWBjgWnS45WVw%40mail.gmail.com%253E>> wrote: > p6 currently says; > > > When more than one suitable response is stored, a cache must use the most recent response (as determined by the Date header field). > > https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p6-cache.html#constructing.responses.from.caches > > ... which was sourced pretty directly from 2616: > > > A correct cache MUST respond to a request with the most up-to-date response held by the cache that is appropriate to the request > > Interpreted strictly*, this means that if a cache has two fresh representations: > > Content-Type: image/jpeg > Date: Thu, 14 Feb 2013 03:08:09 GMT > > Content-Type: image/png > Date: Thu, 14 Feb 2013 03:08:08 GMT > > and it gets a request with: > > Accept: image/jpeg;q=0.1, image/png;q=1.0 > > then it'll return the JPEG because it's fresher, even though the client clearly prefers the PNG. > > However that's not the whole story. To get to those multiple responses, the cache goes through the process of winnowing down the potentially matching stored responses, using the process described in <https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p6-cache.html#caching.negotiated.responses>. > > That section says: > > > If multiple selected responses are available, the most recent response (as determined by the Date header field) is used; see Section 4. > > which I put into p6 based upon the above. > > So, I'm wondering if we should change that to something like: > > """ > If multiple selected responses are available, the cache will need to choose one to use. If a selecting header has a known mechanism for doing so (e.g., qvalues on Accept and similar request headers), it MAY be used to select one; otherwise, the most recent response (as determined by the Date header field) is used, as per Section 4. > """ > > Thoughts? Again, I am the farthest thing from a HTTP cache expert but here are my thoughts based on my numerous readings of the current p6 draft in an attempt to educate myself. Forgive me if I have waded too far into the deep end. It seems to me that the rules in Sections 4 and 4.3 center around the fact that a cached response resulting from proactive content negotiation will include a Vary header, even though the presence of such a header in the server response is a MAY per https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p2-semantics.html#proactive.negotiation. So the (my) question is, what can/should a cache do with multiple stored responses in the absence of any Vary headers, as in your example above? Can the cache use proactive content negotiation headers provided in the request to select the stored response that the client would prefer? Or should the cache not select a response and punt it to the origin server per Section 4.2? -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University
- p6: Returning the freshest response Mark Nottingham
- Re: p6: Returning the freshest response Eitan Adler
- Re: p6: Returning the freshest response Ken Murchison
- Re: p6: Returning the freshest response Martin Thomson
- Re: p6: Returning the freshest response Martin Thomson
- Re: p6: Returning the freshest response Ken Murchison
- Re: p6: Returning the freshest response Martin Thomson
- Re: p6: Returning the freshest response Mark Nottingham
- Re: p6: Returning the freshest response Mark Nottingham
- Re: p6: Returning the freshest response Martin Thomson
- Re: p6: Returning the freshest response Amos Jeffries
- Re: p6: Returning the freshest response Eitan Adler
- Re: p6: Returning the freshest response Martin Thomson
- Re: p6: Returning the freshest response Mark Nottingham
- Re: p6: Returning the freshest response Amos Jeffries
- Re: p6: Returning the freshest response Mark Nottingham
- Re: p6: Returning the freshest response Mark Nottingham
- #453: Returning the freshest response Mark Nottingham
- Re: #453: Returning the freshest response Mark Nottingham