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

Re: Cacheability; MKCOL idempotent?

From: Julian Reschke <julian.reschke@gmx.de>
Date: Wed, 04 Jan 2006 23:16:27 +0100
Message-ID: <43BC493B.4080101@gmx.de>
To: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
CC: webdav <w3c-dist-auth@w3.org>

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 

	"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 

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

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