Re: Thoughts on relation to WebDAV

Werner Baumann wrote:
> 
> Julian Reschke wrote:
>  > There are many ways how a server can refuse to do MKCOL. It can
>  > always claim "forbidden", it can say "not implemented" etc.
>  >
>  > In practice it means the client won't be able to create collections.
> 
> So we need only two status codes in HTTP: success, no success.

No, we need many more.

> Ever occurred to you, that an error code should inform about the reason 
> of the failure and that this reason makes a difference in practice?
> 
> 403 says, the server can create collections, but it will not create 
> *this* collection.
> 501 says, the server is not able to create collections at all.

Yes.

So I'd say that it's better if a server actually states 501 when it 
can't create *any* collections.

> Can't you imagine, that clients and users might react differently in 
> this two cases? Never seen a windows-user, completely mixing up the 
> system configuration, just because of an idiotic, misleading error message?

Is this a rhetoric question?

> RFC 4918 has silently removed the requirement for servers to support 
> MKCOL. This (together with compliance class 3) has lead to confusion 
> (see this thread). But it does not matter in practice?
> Will it not effect the development of clients, whether they can trust in 
> support of MKCOL by all compliant servers? They can always decide to not 
> support badly broken servers, but they can hardly explain why they will 
> not support compliant ones.

The point is that it's not the spec language that will influence the 
decision whether to allow creation of collections or not.

If a server has a data model that supports collections, it will 
implement MKCOL. Otherwise it won't. No matter what the spec says.

So if you want to expose a set of HTTP resources for authoring, and you 
can support all of WebDAV L2 and L3, *except* creating new collections, 
what would you return in the DAV: response header upon OPTIONS?

I bet you'd claim support for MKCOL, return level 3, and then fail the 
request if somebody tries to MKCOL anyway.

> If you buy a WebDAV-server from a vendor and later notice it does not 
> support MKCOL. Does it matter whether this is standard compliant?

So how exactly is it an improvement to the client when the server claims 
it can do MKCOL, but always returns 403? That would be compliant with 
RFC2518, but not helpful it all.

In practice, there are many things that RFC2518 and RFC4918 do not even 
talk about, but will affect conformance and interoperability:

- the set of characters allowed in path segments (think Unicode 
normalization)
- the maximum length of a path segment
- whether or not path segments are case-sensitive
- the maximum number of path segments
- the maximum total lenth
- size constraints for property values
- ...

One key feature of HTTP and protocols based on HTTP is that messages and 
responses are self-descriptive, and that close coupling (as in WS-*) is 
avoided. Yes, it's always nice to know upfront if a server is going to 
allow something (being it out-of-band by spec, by introspection 
(OPTIONS), whatever...). But in practice, a client will have to deal 
with unexpected errors (and yes, good status codes help with that).

> Was the requirement for supporting MKCOL removed by intention or by an 
> editorial mistake. RFC 4918 lists three contributors and one author. One 
> of them (Julian Reschke) says "It wasn't intentional". There is an 
> Errata document with three entries, all by Julian Reschke. But 
> unintentional removal of a WebDAV-method from the requirements is not 
> worth an entry in Errata, because it does not matter in practice.

I did say it should be in the errata. Please raise it.

> I believe internet standards should be taken more seriously.

Nit: RFC4918 is a Proposed Standard. Not an "Internet Standard", at 
least not in RFC speak.

I totally agree that IETF specs should be taken seriously. Believe me, 
if I didn't I certainly wouldn't spend so much time trying to revise them.

BR, Julian

Received on Saturday, 24 May 2008 07:50:08 UTC