Description: ------------ It is not possible to upload a file that contains a slash or a backslash in its name to the WebDAV Server. If the filename contains a slash, the filename is interpreted as a directory name followd by a filename. e.g. foo/bar.txt is interpreted as directoryname "foo" and filename "bar.txt". If the filename contains a backslash, the backslash is silently removed. e.g. foo\bar.txt is interpreted as foobar.txt Test script: --------------- Suggested patches: To solve the backslash problem, it appears to be sufficient, to remove the following lines from function ServeRequest in file Server.php: if (ini_get("magic_quotes_gpc")) { $this->path = stripslashes($this->path); } Solving the slash problem is harder. The problem is, that function _urldecode() is invoked on the whole $_SERVER["PATH_INFO"] variable. With such an approach, slashes in the file name, which were properly encoded by the WebDAV client using the %25 escape sequence, are converted into slash character. The slash characters are later wrongly interpreted as path component delimiters. Suggestion 1: _urldecode should be invoked on the individual path components of the $_SERVER["PATH_INFO"] variable. Also, the path should be stored as as an array of path components in variable $this->path in file Server.php. $this->path = explode('/', $_SERVER['PATH_INFO']); for ($i = 0; $i < count($this->path); $i++) { $this->path[$i] = $this->_urldecode($this->path[$i]); } Caveat: All subclasses of Server.php must now deal with $this->path being an array instead of a string. Suggestion 2: _urldecode should be invoked on the individual path components of the $_SERVER["PATH_INFO"] variable. Then, slashes in the path components should be escaped with another slash, before concatenating the result into the string $this->path. $pathComponents = explode('/', $_SERVER['PATH_INFO']); $this->path = ''; foreach ($pathComponents as $component) { $this->path .= '/'.preg_replace('/\\//','//',$this->_urldecode($component)); } Caveat: Subclasses of Server.php which need to support Unix filenames must now deal with the escaped slash sequences.

before i get into this: why do you have files names with slashes or backslashes at all? each of them is a forbidden character on one of the major OS platforms so i'd rather try to reject them alltogether in the first place than to make sure they work under all circumstances. the risk of confusion on the client side when seeing filenames with characters only supported by "the other" platform is just too big. or am i missing something?

Rationale for supporting backslashes and slashes: ------------------------------------------------- I am integrating WebDAV support into an E-Learning plattform (ILIAS, for more information see http://www.ilias.de ). Courses which start in one year and finish in a following year are often labeled with a slash. e.g. "English Course 2005/06". This kind of writing is commonly used in my language region (Switzerland). Support for backslash is more a nice to have feature, I am only asking for support of backslashes in order to have full support of Unix filenames without restrictions imposed by the webdav server. Rationale for supporting forbidden characters --------------------------------------------- I am going great lengths to have our learning platform work reliably as a virtual file server. Some of our schools work mostly with Windows clients, some mostly with Mac OS X clients. Learning groups with homogeneous clients should be able to reliably exchange files using the virtual file servers without having to worry about issues caused by cross-platform support by the server. On the server I am doing already a lot for cross-platform support. I added code which attempts to guess the client operating system. The code hides hidden Unix-files (filenames starting a ".") from Windows clients. This works very well. Before I added the code, Windows users duly deleted all these "unwanted" files, and I received complaints by Mac OS X users who had lost meta-data of their files. I also added code that deals with differences in the use of Unicode character compositions/decompositions, so that we can reliably exchange file names with diacritics and even non-latin characters in it. (For the Unicode composition/decomposition support I am using a PHP class of MediaWiki, let me know, if you are interested about details). And finally, there are some courses which only use the web-interface of the learning platform. It seems to be unpractical to restrict naming of these courses to the character set supported by the Windows operating system, because many of the forbidden characters are commonly. e.g. we have many objects on our server with a question mark in their name. So far, the Windows WebDAV client handles forbidden characters gracefully. It omits filenames which are not supported by Windows. So, I don't see a need for restricting filenames on the server.

Would it be possible to put the code sequence, which decodes the path into a function of its own, so that subclasses of HTTP_WebDAV_Server can be implemented which fully support Unix filenames? For example, by adding a function named decodePath to to HTTP_WebDAV_Server and calling it from function serveRequest?