Re: Cacheability; MKCOL idempotent?

Geoffrey M Clemm wrote:
> 
> 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.

(also agreed upon in today's conference call).

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

Indeed RFC2616, Section 9.6 
(<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.9.6>):

	"Responses to this method are not cacheable."

So is this a SHOULD NOT or a MUST NOT?

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

We don't have these mechanisms, but that doesn't change the fact that 
real-world client will have to do some kind of caching to get decent 
performance.

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

OK, this clearly is an issue that we can solve quickly :-)

Any objections to update all RFC2518bis method descriptions that 
currently don't say anything about cacheability to use the same language 
as RFC2616 (see above)?

Best regards, Julian

Received on Wednesday, 4 January 2006 22:18:22 UTC