Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (athena.apache.org: local policy)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gbiv.com; h=content-type
	:mime-version:subject:from:in-reply-to:date
	:content-transfer-encoding:message-id:references:to; q=dns; s=
	gbiv.com; b=NH9TY7fYvs7Xn9fwDHofNmEIhnsdMhktsV3UNT2SzYILC92K2Xuz
	S5MSnLZoYkE5VSzTMtVkGWb/90vTWmk7DHhMfAy4oZdG4MghJSpcBiz3M2mJMPCQ
	azQ0ozS0o/tq3mvDEmwoUcmOwWVisQLOrpilTGPWUEfCtZDGNNAelb0=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1082)
Subject: Re: svn commit: r1070179 - in /httpd/httpd/trunk: CHANGES
 docs/manual/mod/mod_cache.xml modules/cache/cache_storage.c
 modules/cache/cache_storage.h modules/cache/mod_cache.c
 modules/cache/mod_cache.h
From: "Roy T. Fielding" <fielding@gbiv.com>
In-Reply-To: <823F6C2D-68BA-4358-937F-8B70BB186719@sharp.fm>
Date: Mon, 14 Feb 2011 00:27:57 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <8754DDEA-5EF9-460B-84C8-39C7D77A72B3@gbiv.com>
References: <20110213020330.953172388900@eris.apache.org>
 <5E44EE80-76CD-4743-B57E-AF90FF0F97EC@gbiv.com>
 <823F6C2D-68BA-4358-937F-8B70BB186719@sharp.fm>
To: dev@httpd.apache.org

On Feb 13, 2011, at 5:03 AM, Graham Leggett wrote:

> On 13 Feb 2011, at 9:59 AM, Roy T. Fielding wrote:
>=20
>>> URL: http://svn.apache.org/viewvc?rev=3D1070179&view=3Drev
>>> Log:
>>> mod_cache: When a request other than GET or HEAD arrives, we must
>>> invalidate existing cache entities as per RFC2616 13.10. PR 15868.
>>=20
>> Cache entries should not be invalidated unless the response comes
>> back as a success (2xx).  Likewise, it only applies to methods with
>> known write effects (not including TRACE, OPTIONS, PROPFIND, etc.).
>>=20
>> This has already been updated in httpbis p6.
>=20
> Hmmm...
>=20
> So is it right to say that POST, PUT and DELETE should invalidate, =
while all others would be left alone?
>=20
> Or do we need some kind of mechanism for modules that respond to new =
methods to declare those methods as needing to be invalidated or not?

Well, I thought I could answer that with a simple link to the
drafts, but they just got changed in the wrong direction.
It should be implemented as invalidating when the response
is 2xx and the method is *not* one of the safe ones
(GET, HEAD, OPTIONS, TRACE, PROPFIND, and maybe REPORT).
That way, a new extension method would invalidate on success.

> Should the cache try and cache any of the other methods, or is =
cacheability limited to GET only?

It can cache other methods if it knows how to.  PROPFIND is
probably the only other method worth caching, but its key
depends on a bunch of webdav stuff outside the URI.

....Roy=