Hello,

I have nginx up and running as WebDAV server on my Linux NAS. This is the server part of my nginx configuration:

server {
listen 443 ssl;
server_name <virtualhostname>;
auth_basic "Restricted";
auth_basic_user_file .htpasswd;
charset utf-8;
root /mnt/HD_a2/WebDAV;
autoindex on;
dav_methods PUT DELETE MKCOL COPY MOVE;
dav_ext_methods PROPFIND OPTIONS;
dav_access user:rw group:rw all:r;
client_body_temp_path /mnt/HD_a2/WebDAV/.temp;
client_max_body_size 15G;
create_full_put_path on;
location / { }
}

On my WinXP computer I installed CyberDuck and Netdrive to access the WebDAV site. Both are configured to use UTF-8. Together with Firefox, which at least allows me to see content and download something, that makes 3 clients.

And tell you something, all behave different!

- Firefox first of all shows all files and folders with correct spelling (correct means "the same as if mounted as smb share")
- CyberDuck doesn't show files and folders if whitespaces are contained in the file/folder name (e.g. "My documents")
- The same for Netdrive, but Netdrive even doesn't show files with special characters (e.g. "ä","ö","ü","ß",...)

OK, thats for reading, now for writing I will concentrate on CyberDuck only, because that client has the nice ability to show http communication quite in detail:
- Create file with special characters in the filename (e.g. "PUT https://<virtualhost>/äöü.txt") -> File is created with correct spelling!
- Create a folder with special characters in the foldername (e.g. "MKCOL https://<virtualhost>/äöü") -> Also works flawlessly!
- Copy file (e.g. COPY äöu.txt https://<virtualhost>/äöu2.txt) -> New file is created with http-spelling ("%C3%84%C3%96%C3%9C2.txt" in this case). These files will still be shown correctly ("äöü2.txt" in this case) in CyberDuck and Netdrive but they will not be accessible in any way (http-error "not found").
- MOVE with special character files shows the same kind of misbehaviour
- MOVE with special character folders results in "conflicts" error (409)
- COPY with special character folders results in "internal server error" if it contains something and if not simply nothing happens

Conclusions:
- The server is setup correctly with respect to reading (firefox reads everything correctly and can access everything)
- At least two client apps have problems reading files/folders with special characters names. Why? How can I work around?
- The COPY and MOVE methods certainly misbehave on server side! IMO there is simply no other explanation, why COPY, MOVE, PUT and MKCOL should create destination files with exactly the same URI in different ways! Is this a known bug? Is there a solution?

best regards
ako673de

Some progress has been made:

The reason for some files and folders not being displayed is a bug in PROPFIND implementation of "nginx-dav-ext-module"!!! Using the latest version in the "uri-encode" branch of their GIT-hub repository (https://github.com/semantico/nginx-dav-ext-module/tree/uri-encode) fixed that issue.

But MOVE and COPY are nginx native functions and these still misbehave. It seems to be a very similar problem to the one in "nginx-dav-ext-module". Please, could anyone fix that?

And there is another bug I observed in conjunction with "Netdrive": It's creating new folders with "MKCOL <foldername>" instead of "MKCOL <foldername>/". nginx however is very picky with that missing "/". The result is a "209" error ("conflicts"). Is that a bug of Netdrive? I don't know, but Netdrive is around for quite a while and nobody seems to have problems with creating folders. IMO a missing "/" should not cause complete failure, especially if the target MUST be a folder (MKCOL)! Is there a way to work this around in the nginx config file? Maybe by some rewrite rule?

best regards
ako673de

ako673de Wrote:
-------------------------------------------------------
> And there is another bug I observed in conjunction with "Netdrive":
> It's creating new folders with "MKCOL <foldername>" instead of "MKCOL
> <foldername>/". nginx however is very picky with that missing "/". The
> result is a "209" error ("conflicts"). Is that a bug of Netdrive? I
> don't know, but Netdrive is around for quite a while and nobody seems
> to have problems with creating folders. IMO a missing "/" should not
> cause complete failure, especially if the target MUST be a folder
> (MKCOL)! Is there a way to work this around in the nginx config file?
> Maybe by some rewrite rule?

Worked around with the following config hack:

if ($request_method = MKCOL) { rewrite ^(.*)/*$ $1/; }

!!!

Still, for the moment "MOVE" and "COPY" methods need to be disabled because they simply do not work. The loss is not too big anyway. You can still download, (delete), and reupload, which is the same as MOVE or COPY... but still should be fixed if you find the time.

Have you tried setting compatibility mode to On within Netdrive ? this might be a Netdrive problem.

Sorry, that is definitively sorted out. It IS a bug in nginx! It happens with all non ASCII characters, that need to be escaped with "%" in the request "destination" header (which is in use only by MOVE and COPY).

I give you an example:

Rename (=MOVE) file "<www-root>/TheCore.ogm" to "<www-root>/The_Core.ogm":

Request header:
--> MOVE http://andinas/TheCore.ogm HTTP/1.1
--> Destination: http://andinas/The_Core.ogm
Response header:
--> HTTP/1.1 204 No Content
--> Server: nginx/1.5.6
Result: File renamed to "The_Core.ogm". Fine!

Now rename (=MOVE) file "<www-root>/andinas/The_Core.ogm" to "<www-root>/andinas/The_ Core.ogm" (notice the blank after the underscore, but the same is true for äöüß and the like!):

Request header:
--> MOVE http://andinas/The_Core.ogm HTTP/1.1
--> Destination: http://andinas/The_%20Core.ogm
Response header:
--> HTTP/1.1 204 No Content
--> Server: nginx/1.5.6
Result: File renamed to "The_%20Core.ogm". Not so fine!

The escaped blank is treated by nginx MOVE as it was not escaped! That is definitvely bad behaviour.

What do I need to do to get this fixed. Can I file an issue directly. Or will somebody take over automatically now.


BTW: I seem to have encountered a similar issue with this config-file lines:
--> if ( $http_destination ~ https?://[^/]+/(.*) ) { set $httpdest http://localhost:8008/$remote_user/$1; }

(for this (working!) code that makes the destination header ready for proxy_pass to another webdav server with user dependent base folders (pyWebDav allows only one user :-/):
--> proxy_set_header Destination $httpdest;
--> proxy_pass http://127.0.0.1:8008/$remote_user$request_uri;
).

Here again, if $http_destination contains the perfectly correct escaped characters from the webdav client, the resulting $httpdest will additionally escape the "escape" characters.

Example:
Destination File = "<www-root>/The_ Core.ogm"
$http_destination = "http://andinas/The_%20Core.ogm" (correct)
$httpdest = "http://andinas/The_%2520Core.ogm" (wrong!)

Obviously here the highly undesirable transformation happens during the regex matching. But why? Can I switch that off somehow?

sorry if it was way too much text :-)
best regards
ako673de

P.S. if you are still reading: There are two very funny things about the
--> proxy_pass http://127.0.0.1:8008/$remote_user$request_uri;
line:
1) You cannot use localhost here. nginx needs a resolver as soon as there is a variable in the string. And at least I didn't manage to find a resolver that can resolve localhost.
2) Nowhere in the internet is been said, that you need to add $request_uri to the line. You do need! And it must not be $uri, because that has the same escaping issues like the other things I mentioned above.

OK, now I'm done ;-). Please help!

Not sure the devs read here, they do read here http://forum.nginx.org/list.php?2 a repost there might get a response.

done. Thank you.