W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2006

Re: Cacheability; MKCOL idempotent?

From: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Date: Tue, 3 Jan 2006 16:41:01 -0500
To: " webdav" <w3c-dist-auth@w3.org>
Message-ID: <OFBC7C9221.E217449A-ON852570EB.00753F7F-852570EB.00771C16@us.ibm.com>
Julian wrote on 01/03/2006 02:41:38 PM:
> While looking into BugZilla issue 80 ("Specify idempotence and safeness 
> for all new methods", 
> <http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=80>), I noticed 
> that RFC2518 says that MKCOL's results aren't cacheable because it's not 

> idempotent (see 
> <http://greenbytes.de/tech/webdav/draft-reschke-webdav-rfc2518bis-
> latest.html#rfc.change.bz080.3>). 
> I think that's incorrect, because similar to PUT, repeating the same 
> MKCOL request multiple times will cause the server to have the same 
> state afterwards (just like PUT, but unlike POST).

I agree.  MKCOL is idempotent.

> So I fixed that, but wonder: should this affect what we say about the 
> cacheability of MKCOL results? Are we still saying "MUST NOT be cached"?

Yes (just as PUT must not be cached).

> As a matter of fact, should we rethink that for all methods? We 
> currently say that PROPFIND results SHOULD NOT be cached 
> (<http://greenbytes.de/tech/webdav/draft-reschke-webdav-rfc2518bis-
> latest.html#rfc.section.8.2>). 

PROPFIND isn't cacheable because we don't provide any
cache-validity mechanisms for properties (such as etag or last-modified).

> Is there any good reason for it? Should the fact that real-world WebDAV 
> clients *do* cache PROPFIND results tell us something? :-)

Just tells us that there are buggy clients out there (:-).

Received on Tuesday, 3 January 2006 21:41:21 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:34 UTC