Re: Cacheability; MKCOL idempotent?

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 (:-).

Cheers,
Geoff