IETF Logo Mail Archive

Re: Questions (errata?) about caching authenticated responses [#174]

Mark Nottingham <mnot@mnot.net> Sat, 25 July 2009 00:35 UTC

Return-Path: <ietf-http-wg-request@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@core3.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A2C33A6930 for <ietfarch-httpbisa-archive-bis2Juki@core3.amsl.com>; Fri, 24 Jul 2009 17:35:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.042
X-Spam-Level:
X-Spam-Status: No, score=-9.042 tagged_above=-999 required=5 tests=[AWL=1.557, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iQfroioI4xGT for <ietfarch-httpbisa-archive-bis2Juki@core3.amsl.com>; Fri, 24 Jul 2009 17:35:38 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 67FC23A691C for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 24 Jul 2009 17:35:38 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1MUVE5-0004Uy-Je for ietf-http-wg-dist@listhub.w3.org; Sat, 25 Jul 2009 00:35:01 +0000
Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from <mnot@mnot.net>) id 1MUVDy-0004R5-QB for ietf-http-wg@listhub.w3.org; Sat, 25 Jul 2009 00:34:55 +0000
Received: from mxout-08.mxes.net ([216.86.168.183]) by maggie.w3.org with esmtp (Exim 4.63) (envelope-from <mnot@mnot.net>) id 1MUVDp-0004Kz-6s for ietf-http-wg@w3.org; Sat, 25 Jul 2009 00:34:54 +0000
Received: from [192.168.1.6] (unknown [121.44.193.184]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id DEE3A509D9; Fri, 24 Jul 2009 20:34:15 -0400 (EDT)
From: Mark Nottingham <mnot@mnot.net>
To: Henrik Nordstrom <henrik@henriknordstrom.net>
In-Reply-To: <1248477546.31377.139.camel@localhost.localdomain>
References: <Pine.SGI.4.10.10007192325560.19376-100000@surf.ircache.net> <C8E9A095-6F76-4767-A1C5-72940AD268F3@mnot.net> <4BECFD62-55E9-45D5-9CF0-3B18DF51C37F@mnot.net> <1248477546.31377.139.camel@localhost.localdomain>
Message-Id: <A211E17D-31B2-4095-B240-BA7A7BC16E98@mnot.net>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Date: Sat, 25 Jul 2009 10:34:10 +1000
Cc: HTTP Working Group <ietf-http-wg@w3.org>, Duane Wessels <wessels@packet-pushers.com>
X-Mailer: Apple Mail (2.935.3)
Received-SPF: pass
X-SPF-Guess: pass
X-W3C-Hub-Spam-Status: No, score=-2.6
X-W3C-Hub-Spam-Report: BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001
X-W3C-Scan-Sig: maggie.w3.org 1MUVDp-0004Kz-6s d9a8a914fca23cc85b024a971d399b84
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Questions (errata?) about caching authenticated responses [#174]
Archived-At: <http://www.w3.org/mid/A211E17D-31B2-4095-B240-BA7A7BC16E98@mnot.net>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/7268
X-Loop: ietf-http-wg@w3.org
Sender: ietf-http-wg-request@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-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <E1MUVE5-0004Uy-Je@frink.w3.org>
Resent-Date: Sat, 25 Jul 2009 00:35:01 +0000

<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/174>

On 25/07/2009, at 9:19 AM, Henrik Nordstrom wrote:

> Making that decision on must-revalidate just feels odd to me as it's  
> not
> what must-revalidate is about. In all other aspects must-revalidate
> places further restrictions on the cache (shared & private), not
> enabling.

Agreed.

> Maybe we may change the implementation regarding s-maxage to implicit
> assume public when s-maxage is used as this is an explicit instruction
> for a shared cache which does not make sense to see on private  
> content.
> But it then begs the question if proxy-revalidate also means public,
> which it probably should do by the same reasoning.

Yes. My inclination here would be to make it as simple as possible,  
keeping in mind the behaviour of current implementations.


> Perhaps the intention actually was to use proxy-revalidate in that  
> text
> and not must-revalidate. If proxy-revalidate is substituted in that  
> text
> then it becomes coherent and makes some sense. But I do not know if  
> that
> was the intention as I was not around in the discussions then. I
> probably could have been but were not as I was not familiar with the
> workings of IETF then.


I had a quick look through the old caching list and didn't find  
anything, but this list's predecessor had a few relevant bits:


   http://lists.w3.org/Archives/Public/ietf-http-wg-old/1996MayAug/0470.html
   http://lists.w3.org/Archives/Public/ietf-http-wg-old/1996MayAug/0473.html

   http://lists.w3.org/Archives/Public/ietf-http-wg-old/1996SepDec/0578.html
   http://lists.w3.org/Archives/Public/ietf-http-wg-old/1996SepDec/0582.html
   http://ftp.ics.uci.edu/pub/ietf/http/draft-mogul-http-revalidate-01.txt

   http://lists.w3.org/Archives/Public/ietf-http-wg-old/1998MayAug/0133.html
   http://lists.w3.org/Archives/Public/ietf-http-wg-old/1998MayAug/0137.html

(still looking through these to draw my own conclusion)


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

v2.23.0 | Report a Bug | By Email