Hello! On Thu, Oct 03, 2013 at 10:40:09AM -0430, lcol...@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://lcol...@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://lcol...@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 _______________________________________________ nginx-devel mailing list nginx-devel@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel
