[PATCH 0 of 1] Dav: Changes in the destination header in MOVE and DELETE methods for files and/or folders

Thu Oct 3 16:08:30 UTC 2013

Hello!

On Thu, Oct 03, 2013 at 10:40:09AM -0430, lcolina at cenditel.gob.ve wrote:

> Dear nginx developers,
> 
> The dav module of nginx was tested with client Nautilus 3.4.2 to 
> implement a shared file system in operations office.
> 
> While testing the ngx_http_dav_module, found some conflicts that 
> are described below:
> 
> 1. In operations with MOVE method for files and/or directories: 
> It was found a conflict with the destination header, because 
> Nautilus client sends the URI with the user name, but the user 
> name in the destination header is not supported by nginx, 
> resulting in the following error.
> 
> acesses_log:
> - - 192.168.12.229 - lcolina [27/Sep/2013:09:37:19 -0430] MOVE /data/imagenes/imagen2 HTTP/1.1 "400" 166 "-" "gvfs/1.12.3" "-" 
> 
> error_log:
> 2013/09/27 09:37:19 [debug] 18900#0: *145 http process request header line 
> 2013/09/27 09:37:19 [debug] 18900#0: *145 http header: "Host: webdav.org.ve" 
> 2013/09/27 09:37:19 [debug] 18900#0: *145 http header: "Destination: https://lcolina@webdav.org.ve/data/imagenes/imagen" 
> 2013/09/27 09:37:19 [debug] 18900#0: *145 http header: "Overwrite: F"
> 2013/09/27 09:37:19 [error] 18900#0: *145 "Destination" URI "https://lcolina@webdav.org.ve/data/imagenes/imagen" is handled by different repository than the source URI while sending to client, client: 192.168.12.229, server: webdav.org.ve, request: "MOVE /data/imagenes/imagen2 HTTP/1.1", host: "webdav.org.ve" 
> 
> I think this should be changed because according to the standard 
> is optional URI that contains the user information. So nginx 
> should be able to handle the URI with the user name or not. “The 
> user information, if present, is followed by a commercial 
> at-sign ("@") that delimits it from the host.”

There is no "userinfo" in a http scheme URLs syntax as per 
RFC2616.  Quote from 
http://tools.ietf.org/html/rfc2616#section-3.2:

   The "http" scheme is used to locate network resources via the HTTP
   protocol. This section defines the scheme-specific syntax and
   semantics for http URLs.

   http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]

Upcoming work of httpbis explicitly prohibts use of userinfo in 
http messages, see 
http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-24#section-2.7.1:

   The URI generic syntax for authority also includes a deprecated
   userinfo subcomponent ([RFC3986], Section 3.2.1) for including user
   authentication information in the URI.  Some implementations make use
   of the userinfo component for internal configuration of
   authentication information, such as within command invocation
   options, configuration files, or bookmark lists, even though such
   usage might expose a user identifier or password.  A sender MUST NOT
   generate the userinfo subcomponent (and its "@" delimiter) when an
   "http" URI reference is generated within a message as a request
   target or header field value.  Before making use of an "http" URI
   reference received from an untrusted source, a recipient ought to
   parse for userinfo and treat its presence as an error; it is likely
   being used to obscure the authority for the sake of phishing attacks.

There is no userinfo support in nginx, and it's intentional.  And, 
as the above links show, this seems to agree with standards.

> 2. In operations with MOVE method for directories: It was found 
> a conflict when rename a folder from Nautilus client,  the 
> source path contains no final slash, resulting a bad request 
> error because nginx requires source path with final slash.
> 
> acesses_log:
> - - 192.168.12.229 - lcolina [27/Sep/2013:11:08:34 -0430] MOVE /data/repositorio HTTP/1.1 "400" 166 "-" "gvfs/1.12.3" "-" 
> 
> error_log:
> 2013/09/27 11:08:34 [debug] 27733#0: *146 http copy from: "/srv/data/repositorio" 
> 2013/09/27 11:08:34 [debug] 27733#0: *146 http copy to: "/srv/data/repositorio1" 
> 2013/09/27 11:08:34 [error] 27733#0: *146 "/data/repositorio" is collection while sending to client, client: 192.168.12.229, server: webdav.org.ve, request: "MOVE /data/repositorio HTTP/1.1", host: "webdav.org.ve" 
> 2013/09/27 11:08:34 [debug] 27733#0: *146 http finalize request: 400, "/data/repositorio?" a:1, c:1 
> 2013/09/27 11:08:34 [debug] 27733#0: *146 http special response: 400, "/data/repositorio?" 
> 2013/09/27 11:08:34 [debug] 27733#0: *146 http set discard body 
> 2013/09/27 11:08:34 [debug] 27733#0: *146 xslt filter header 
> 2013/09/27 11:08:34 [debug] 27733#0: *146 HTTP/1.1 400 Bad Request 
> 
> I think this should be changed because according to the standard 
> not mandatory if the directory path contains final slash. So 
> nginx should be able to handle the source path with final slash 
> or not.
> This conflict is solved in line @@ -736,10 +745,9 @@ the patch below.

The collection identifier is with trailing slash, as in 
conformance with RFC 4918, http://tools.ietf.org/html/rfc4918#section-8.3:

   Identifiers for collections SHOULD end in a '/' character.

Suggested patch seems to try to implement the MAY clause from
http://tools.ietf.org/html/rfc4918#section-5.2:

   There is a standing convention that when a collection is referred to
   by its name without a trailing slash, the server MAY handle the
   request as if the trailing slash were present.  In this case, it
   SHOULD return a Content-Location header in the response, pointing to
   the URL ending with the "/".  For example, if a client invokes a
   method on http://example.com/blah (no trailing slash), the server may
   respond as if the operation were invoked on http://example.com/blah/
   (trailing slash), and should return a Content-Location header with
   the value http://example.com/blah/.  Wherever a server produces a URL
   referring to a collection, the server SHOULD include the trailing
   slash.  In general, clients SHOULD use the trailing slash form of
   collection names.  If clients do not use the trailing slash form the
   client needs to be prepared to see a redirect response.  Clients will
   find the DAV:resourcetype property more reliable than the URL to find
   out if a resource is a collection.

But it clearly lacks Content-Location.  And it may be much better 
idea to change the client to follow SHOULD clauses instead (or 
find out a reason why it doesn't in your case).

We may consider returning redirects in such cases with trailing 
slash added, much like it currently happens on GET requests.  But 
I tend to think that it would be better to preserve 400.

> 3. In operations with DELETE method for directories: It was 
> found a conflict when delete a folder from Nautilus client, the 
> directory path to eliminate contains no final slash, causing a 
> conflict because nginx requires source path with final slash, 
> similar to the case number 2.

See above.

-- 
Maxim Dounin
http://nginx.org/en/donation.html