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