W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > July to September 2001

RE: How Clients find out if they can perform a checkout

From: Stefan Eissing <stefan.eissing@greenbytes.de>
Date: Fri, 27 Jul 2001 15:42:12 +0200
To: "Clemm, Geoff" <gclemm@rational.com>, <ietf-dav-versioning@w3.org>
Message-ID: <NDBBKJABLJNMLJELONBKCEFOCPAA.stefan.eissing@greenbytes.de>
> [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Clemm, Geoff
>    From: Stefan Eissing [mailto:stefan.eissing@greenbytes.de]
>    > From: Geoff Clemm
>    > ... in general "supported" means that the method might succeed on
>    > some state of the resource, while the Allow set indicates whether
>    > the method might succeed on the current state of the resource.  I
>    > agree this is worth stating in the protocol (if people agree with
>    > this characterization).
>    Oh, let's not be too subtle in DeltaV, please.
>    From RFC 2616, Ch. 14.7 "Allow", first sentence:
>    "The Allow entity-header field lists the set of methods 
> supported by the
>    resource identified by the Request-URI."
>    Now, how could that be different from a "supported-method-set"?
> You need to look at the other sections of RFC 2616 that discuss Allow.
> In particular, in section 5.1.1:
>    The list of methods allowed by a resource can be specified in an
>    Allow header field (section 14.7). The return code of the response
>    always notifies the client whether a method is currently allowed on
>    a resource, since the set of allowed methods can change
>    dynamically.
> I believe this makes it clear that "allow" means "might succeed on the
> current state of the resource" as opposed to "might succeed on some
> state of the resource".  This distinction is very important, because
> the latter would probably be used to determine what the menu for that
> resource would contain, while the former would be used to determine
> which entries in this menu should be "greyed out".

Well, you excluded how section 5.1.1 continues:

	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

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.

But this may be bean counting...

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.

So I repeat: Let's not be too subtle in deltaV, please.

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.

...which (OPTIONS) would have otherwise been necessary...

...as DAV:supported-live-property-set does not tell the whole story...

...as there is no DAV:resourcetype.

There! I said it! Dirty word, dirty word...

Received on Friday, 27 July 2001 09:42:37 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:47 UTC