Re: Thoughts on relation to WebDAV

Werner Baumann wrote:
> Julian Reschke wrote:
>> But most of the time, a client doesn't need to know that. For 
>> instance, when displaying folder contents. Either PROPFIND is there or 
>> not. What other parts of WebDAV are there is just irrelevant for that.
>>
> Whether the server believes it is irrelevant does not matter. When the 
> server announces full support for WebDAV, using the DAV-header, the 
> client is allowed to interpret it according to the specification. When 
> this causes trouble, the responsibility is on the side of the server 
> that intentionally sent wrong information.

Yes.

> Now, as you would not have removed the DAV-header anyway, you ought to 
> respect it, as defined in the specification. If you want to deprecate 
> it, say it loud and *clear*. What I oppose is your suggestion to 
> intentionally misuse it (Send DAV: 1 and not support required methods) 
> and this way render it useless.

I disagree that it renders it useless. It isn't very useful in the first 
place.

And the only reason to deprecate it would be because it may harm usage 
WebDAV for novel things, such as Vcarddav.

>> Getting back to what got us here (I think): are you saying that a 
>> server that exposes a flat collection of items (such a set of vcards) 
>> is not allowed to say "I'm doing WebDAV" because it doesn't allow 
>> creating child collections?
>>
> Looks like a CardDav (?) problem, and they really seem to be in trouble 
> here. If they really want to restrict to flat collections, which means 
> no MKCOL, they are not compliant to WebDAV and should not use the 
> DAV-header (you don't like it anyway). But as they intend to create an 
> extension protocol, there surely is way to handle this properly.

Yes, maybe it's better to not to use the header for them. The problem is 
that it'll make it *much* harder to specify the protocol, with little 
real-world advantage.

>> Do you have evidence of a server that actually *does* support 
>> arbitrarily deeply nested collections? What am I missing here?
>>
> Not allowing arbitrarily deeply nested collections is not the same as 
> not allowing the creation of collections at all. This looks like a use 
> case for 403, according to the specs.

So, at what nesting level do you draw the line? Any spec text to support 
that?

>>> 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)
> As far as I know unicode is allowed in pathsegments and there is a rule, 
> how to escape them. The practical issue seem to me different reserved 
> characters on different operating systems. I have know solution, but 
> education. Perhaps servers should reject pathnames that cry for trouble.

Well. Servers do.

A server that stores path segments as unicode will likely reject a path 
segment of "%80", because it's not a legal UTF-8 octet sequence.

So, what do you do in a Unix setup where the local filename contains a 
single 0x80 octet, and the user wants to copy the file to that WebDAV 
server?

>>> - whether or not path segments are case-sensitive
> Neither servers nor clients should change the case.

So what about case-preserving vs case-sensitive? Many servers do 
preserve the case, but can't store things that only differ in case, such 
as "Makefile" vs "makefile", to name a popular example.

Compliant?

>>> - the maximum length of a path segment
>>> - the maximum number of path segments
>>> - the maximum total lenth
>>> - size constraints for property values
> Are these real problems today. As long as people have a minimum of good 
> taste, there should not be a problem. In most other cases servers are 
> allowed to simply reject such request.

Yes, but this is something RFC4918 is totally silent about. So where do 
you draw the line between where servers a free to have restrictions, and 
where not?

>>> 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).
>>
> This could be arguments, when you start an *open* discussion to remove 
> the DAV-header from the spec.
> 
> 
>> Let me add a few more:
>>
>> - whether path segments are stored as is (using URI escaping), byte 
>> sequences (Unix/Posix file IO) or character sequences (Windows, HFS+)
>>
>> - how trailing blanks are handled (ignored vs stored)
>>
>> - how trailing dots are handled
>>
> I think "store" or not "store" is not in the scope of the spec. But 
> neither a server nor a client is allowed to silently change the URL of a 
> resource (and expect it to work) (with the exception when the server 
> forgot about the trailing slash of a collection-URL). If a server does 
> not like a new URL created by a client, it should reject it.

OK, there's go IIS and iDisk (I think).

>> - whether or not content written with PUT can be rewritten by the server
>>
> It is out of the spec what a server is allowed to do with its resources. 
> But in my opinion: regarding distributed authoring, co- and 
> anti-authoring by the server is the last think we need.
> 
> BTW: Is anybody, who refuses to accept clear misuse of protocol 
> elements, obliged to answer this - quite unrelated - questions? Is this 
> a test, whether I am allowed to open my mouth when important people are 
> talking about standards?

No, I'm just trying to understand where you draw the line about areas 
where a server may have restrictions that aren't mentioned in the spec.

Not sure about what you mean when you say "important people". Maybe you 
may want to read an FAQ about the IETF process...

BR, Julian

Received on Monday, 26 May 2008 06:00:44 UTC