Subject: Cacheability; MKCOL idempotent?

From: Julian Reschke <[email-masked]>
Date: Tue, 03 Jan 2006 20:41:38 +0100

Hi.

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

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

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

Feedback appreciated,

Julian

---

From: Geoffrey M Clemm <[email-masked]>
Date: Tue, 3 Jan 2006 16:41:01 -0500

> state afterwards (just like PUT, but unlike POST).

I agree.  MKCOL is idempotent.

> cacheability of MKCOL results? Are we still saying "MUST NOT be cached"?

Yes (just as PUT must not be cached).

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

> clients *do* cache PROPFIND results tell us something? :-)

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

Cheers,
Geoff

---

From: Julian Reschke <[email-masked]>
Date: Wed, 04 Jan 2006 23:16:27 +0100

> I agree.  MKCOL is idempotent.

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

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

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

> 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

---

From: Julian Reschke <[email-masked]>
Date: Wed, 04 Jan 2006 23:28:06 +0100

Julian Reschke wrote:
> ...
> ...

s/can/can't/

jr