cachefilter improvements?

[Aamer]

I was dicussing an issue I saw with the cachefilter on the IRC channel
today.

Basically, the issue is that the cache filter matches items in the
cache based on the URL. This means that if you have any post
information, it is ignored.

This is causing problems on a project I'm working on because whenever a
user posts a form, the request won't go through until the cache
expires.

Someone suggested that the cachefilter should only serve GET requests.
I was thinking another possibility (though this would add some
overhead) is to store a hash of the url along with all the post
parameters.

Any thoughts?

[Uche Ogbuji]

Aamer wrote:
> Someone suggested that the cachefilter should only serve GET requests.
> I was thinking another possibility (though this would add some
> overhead) is to store a hash of the url along with all the post
> parameters.
>
> Any thoughts?

I think that's a very bad idea. GETs are supposed to be idempotent.
POSTs are not, so caching a post violates at least the spirit of HTTP.
If you happen to be using POST in your app in such a way that it does
make sense to cache it, that should be an app-specific extension, but
caching POSTs (or PUs, DELETEs, etc.) should not be made part of the
core filter.

--
Uche Ogbuji Fourthought, Inc.
http://uche.ogbuji.net http://fourthought.com
http://copia.ogbuji.net http://4Suite.org
Articles: http://uche.ogbuji.net/tech/publications/

[Aamer]

Uche, definitely PUT and DELETE should not be cached. As for POSTs,
yeah, I think you make a reasonable point there: if your need to cache
it, it should be app-specific.

I am willing to go with the idea that only GET requests should be
cached.

Who originally wrote the cachefilter? Was it Bob Brewer? If so, Bob,
could you give your thoughts on this issue ... because maybe I don't
understand something about how the cachefilter works.

If we're all in agreement about caching only GETs, I can submit a
ticket and patch for this. Should probably only take one line of code
to fix.

[Remi Delon]

> Uche, definitely PUT and DELETE should not be cached. As for POSTs,
> yeah, I think you make a reasonable point there: if your need to cache
> it, it should be app-specific.
>
> I am willing to go with the idea that only GET requests should be
> cached.
>
> Who originally wrote the cachefilter? Was it Bob Brewer? If so, Bob,
> could you give your thoughts on this issue ... because maybe I don't
> understand something about how the cachefilter works.
>
> If we're all in agreement about caching only GETs, I can submit a
> ticket and patch for this. Should probably only take one line of code
> to fix.

Look at the code for the filter:
http://www.cherrypy.org/file/trunk/cherrypy/filters/cachefilter.py

It's possible to configure the cache key (the default is
cherrypy.request.browser_url).
I think that the best way to do it is to derive the MemoryCache class and
override the _key method.
Then you tell the filter what the new class is (by setting the
cache_filter.cacheClass config option) (it needs to be lowercasified BTW
...)

Remi.

[Aamer]

But shouldn't the default configuration ignore POST requests? I don't
see why a user should have to create a derived class just to make the
caching behave the way it is supposed to :-)

It seems to me that caching should work "out-of-the-box" without having
to make any modifications.

Aamer

P.S. Without trying to get off-topic, I was wondering .. is there
anyway to set the CacheClass in a config file? I try to keep my config
options in the config file rather than passing in a dictionary of
settings in the code.

[Robert Brewer]

Aamer wrote:
> Uche, definitely PUT and DELETE should not be cached.
> As for POSTs, yeah, I think you make a reasonable point
> there: if your need to cache it, it should be app-specific.

I'm not sure how much rope to give people on this. RFC 2616 says "Some HTTP methods MUST cause a cache to invalidate an entity. This is either the entity referred to by the Request-URI, or by the Location or Content-Location headers (if present). These methods are: PUT, DELETE, POST"

> I am willing to go with the idea that only GET requests
> should be cached.

I think it should be the inverse: all methods other than PUT, DELETE, and POST should be cached by default, with an option to override that list.

> Who originally wrote the cachefilter? Was it Bob Brewer?

Nope, it was Carlos in ticket 21 and changeset 141. SVN blame is your friend. ;) I never use the silly thing, since all my cache-able pages are handled by the staticfilter.


Robert Brewer
System Architect
Amor Ministries
fuma...@amor.org

[Carlos Ribeiro]

On 4/12/06, Aamer <aamerab...@gmail.com> wrote:

Uche, definitely PUT and DELETE should not be cached.  As for POSTs,
yeah, I think you make a reasonable point there: if your need to cache
it, it should be app-specific.

I am willing to go with the idea that only GET requests should be
cached.

Who originally wrote the cachefilter? Was it Bob Brewer?  If so, Bob,
could you give your thoughts on this issue ... because maybe I don't
understand something about how the cachefilter works.

The original code is mine, and is actually a quick hack that "kind of" worked well enough at the time. At the time I had some ideas to improve it, but I've never had time to check it later. I think I can still remember one or two about the code if needed though - drop me a line if you need it.

--
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: carri...@gmail.com
mail: carri...@yahoo.com

[Aamer]

Thanks Robert and Carlos. The code seems fine to me other than the
issue I mentioned.

In light of the RFC Robert mentioned, I guess the solution is to just
disable caching for POST, PUT, and DELETE if we are all in agreement
here.