- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Mon, 26 May 2008 12:52:18 +0200
- To: Werner Baumann <werner.baumann@onlinehome.de>
- CC: w3c-dist-auth@w3.org
Werner Baumann wrote: > (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 +1! > 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. So, you expect "%80" to work (meaning, be stored and roundtripped) with any compliant server? Well, then the set of compliant servers just got much smaller :-) >>>>> - 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. It doesn't change the case, it would just disallow both of them to be present in the same collection. > 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. Well, only using lower case ASCII is something that's not sufficient once you leave the experimental space. Users expect that they can assign names in their own languages. > ... BR, Julian
Received on Monday, 26 May 2008 10:53:03 UTC