Re: Thoughts on relation to WebDAV

Werner Baumann wrote:
>> 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.
>>
> What was the bet about? A barrel of beer? You lost the bet.

So, what would you do instead then?

Sell a server or service that doesn't work with several popular clients?

>>> 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.
>>
> 
> It is not an improvement at all. In my opinion it would be fraud.
> A server that does not support creation of collections is *not* 
> compliant with RFC 2518 (and, I hope, with RFC 4918 neither) and must 
> not send a DAV-header at all. Hiding this none-compliance by misusing 
> 403 makes things worse.

Well, sorry. It seems we live in different worlds then.

If you insist on that ideal world you'll probably never find a fully 
compliant server (not because of MKCOL, but because of the more subtle 
problems I mentioned -- I noticed you didn't follow up on these...).

> This does not mean, that it is not allowed to create and use servers and 
> clients, that do not meet all requirements of the standard (or the 
> proposed standard), and therefore are not compliant. But these needs to 
> be documented and server and clients will need out of band information 
> about their capabilities to be set up properly. There will be no 
> guarantee for interoperability with other clients or servers. These 
> cases are outside the spec.

That's true.

The problem arises when clients use in-band information for the wrong 
purpose; for instance refuse to use PROPFIND, just because OPTIONS 
doesn't return a DAV header.

In reality you need to deal with these kinds of clients, at least if you 
don't have the luxury to tell the customers just to get a different client.

BR, Julian

Received on Sunday, 25 May 2008 15:42:53 UTC