Re: Thoughts on relation to WebDAV

Julian Reschke wrote:
(concerning the DAV-header, Werner)
> 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.

> 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.
>
That is exactly the point I wanted to make:
They intend to make their new protocol an extension of WebDAV. It turns 
out that WebDAV does not really suit their needs. What they could do:
- rethink, whether WebDAV was a good choice, and maybe make
   it an extension to HTTP, or create a completely separate protocol
- propose to chance the WebDAV-specification. This will need consensus
   and will take a lot of time.
What must not be done: break elements of the WebDAV-protocol 
(DAV-header, 403 status code) because it is easier for them.
While you only see little real-world advantage in going the "*much* 
harder" way, I see the disadvantage of breaking protocols.

(arbitrarily deeply nested collections)
> So, at what nesting level do you draw the line? Any spec text to support 
> that?
>
I do not draw a line and the spec should not do it either. Everybody 
knows that the resources of any server are limited. There is no chance 
to draw a line that meets the needs of the most restricted servers and 
at the same time does not put unnecessary and annoying restrictions on 
others. When a server reaches its limits, it is allowed to reject the 
request with an appropriate status code. Including a more informative 
error message in the body would be good behaviour.


> 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?
>
%80 is the escaped form. Clients and servers must always use this form 
on the wire. How they are going to remember it, and how they like to 
present it to the user (we don't want to be file system fixated) is out 
of the spec.
>>>> - 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?
>
Changing the case, changes the URL and is not compliant.
All these file name issues cannot be solved by HTTP or WebDAV. They are 
indeed a problem and they are an heritage. There are different operating 
systems with different restrictions and different character sets. Now 
they have to cooperate over WebDAV. It will not be possible to map these 
specialities seamlessly from one OS to another; and there is no use in 
trying. I only see two "solutions"
- hope for universal use of utf-8
- educate the users; don't suggest them everything can be used as a file 
name (e.g. the first two paragraphs of a Word document); for the time 
being, only use lower case ascii, never use characters with special 
meaning in any operating systems file system. WebDAV-applications can 
support this, but rejecting bad file names and informing the user about it.

>>> - 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).
>
Bad for IIS and iDisk and annoying for clients that may have to do 
another workaround for broken, but widely used servers; but no reason to 
change the spec. But as said before: nobody should willingly create 
idiotic file names, that are known to ask for trouble.

Werner

Received on Monday, 26 May 2008 08:13:11 UTC