- From: Clemm, Geoff <gclemm@rational.com>
- Date: Thu, 2 Aug 2001 22:04:13 -0400
- To: ietf-dav-versioning@w3.org
From: Stefan Eissing [mailto:stefan.eissing@greenbytes.de]
RFC2518: An origin server SHOULD return the status code 405
(Method Not Allowed) if the method is known by the origin server
but not allowed for the requested resource, and 501 (Not
Implemented) if the method is unrecognized or not implemented by
the origin server.
So, if a resource is locked exclusively, this means that a LOCK
request will not succeed and should not be part of the Allow
header. Fine, but then RFC 2518 defines different response codes
(namely 412 and 423) for a LOCK on a locked resource, ignoring the
SHOULD in RFC 2616.
I don't see a problem here. RFC 2616 cannot be expected to predict
the extended status values that will be defined by an HTTP extension
such as WebDAV.
But this may be bean counting...
Yes. (:-).
However, taking the client view again, the Allow header is not as
useful as you make it look. Apart from Apache/moddav, all servers
include many more methods in the Allow header than one might expect.
IIS and Sharemation, for example, both report MKCOL as allowed method
on a collection.
Using the combination of the Allow header and the DAV:supported-method-set
to do interesting things is of course only relevant when the server
supports the DAV:supported-method-set property.
So I repeat: Let's not be too subtle in deltaV, please.
I think the distinction between "supported by some state of the
resource" and "supported by the current state of the resource"
is not overly subtle. But I don't really care all that much
(and the spec currently is silent on the issue, so we can chose
to defer this question).
Until your mail, which started this thread, I regarded DAV:supported-
method-set as an optimization, sparing clients the OPTIONS requests
on all resources which it got with PROPFIND/Depth 1.
That is certainly something it is useful for.
Cheers,
Geoff
Received on Thursday, 2 August 2001 22:04:44 UTC