Hello, Thanks for taking the time to revise the patch our team is proposing. We know it concerns to some small details in a module that perhaps is not frequently used, and therefore appreciate the attention received. Some comments follow.
El 03/10/13 11:38, Maxim Dounin escribió: > Hello! > > On Thu, Oct 03, 2013 at 10:40:09AM -0430, [email protected] 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. [...] > > 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. > We thought that the syntax described in http://tools.ietf.org/html/rfc3986#section-3 was directly appliable, the provision of http://tools.ietf.org/html/rfc3986#section-1.1.1 that reads: "(...) the URI syntax is a federated and extensible naming system wherein each scheme's specification may further restrict the syntax and semantics of identifiers using that scheme." and the details of http scheme URL syntax were overlooked. Sorry for the confusion. Therefore it follows that the client (Nautilus 3.4.2, via gvfs 1.12.3) fails to comply the standard and a bug report could be in order. To workaround this client failure, a rewrite of Destination header at configuration level may be the appropiate approach. As those client software is widely deployed, it could be considered the inclusion of some remarks about this bug in WebDAV module documentation. >> 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. [...] > > 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. > A brief revision of gvfs dav backend source code available in: https://git.gnome.org/browse/gvfs/tree/daemon/gvfsbackenddav.c shows that, if not present, a trailing slash is added in function g_vfs_backend_dav_uri_for_path for operations where is known that the target is a directory (make_directory and propfind with depth>0). In other cases pathnames provided by outer software layers are not changed. Browsing through gvfsjobmove.c and gvfsjob.c, part of those upper layers, and a brief revision of https://wiki.gnome.org/gvfs/doc and https://developer.gnome.org/gio/stable/ch01.html shows that this client software seems to use POSIX semantics for the pathnames everywhere. In those semantics rename operations doesn't need to know if the target file is a regular one, a directory or some other kind of file and that information is therefore not sent to inner software layers. As in POSIX pathnames trailing slashes are optional and directories are considered a type of file in that standard, in gvfs the DAV backend has apparently been delegated the task of finding out if a trailing slash should be added to a pathname when building the associated URI. In the DAV backend, in order to find out if a pathname is associated with a file or a directory, a PROPFIND request could be sent or the MOVE request could be sent with the pathname unchanged and a provision be made to handle an eventual redirect response. The second approach is being used in gvfs, perhaps because it reduces the number of requests in the case of regular files. That could be the reason for which gvfs doesn't follow in all cases the RFC 4918 SHOULD clause on collection URIs. RFC4918 doesn't seem to have an imperative clause establishing the appropriate server behavior when it chooses not to handle a request in which a collection is referred without a trailing slash in the URI as if that slash were present. However, from the quoted 5.2 section may be inferred that after sending such a request, the client software should expect either a regular response with a Content-Location header or a redirect response. An error response is not mentioned and, when considering if that is the appliable default behaviour, at least one should examine what would be the erroneous behaviour that response would be complaining to the clients. The only fault I can see would be the asumption that either a regular or a redirect response will be received if a URI sent in a request without trailing slash happened to be associated to a collection resource. If the standard provision were that a collection URI MUST have a trailing slash the story would be different, but that is not the case. Based on the rationale just discussed, I think that the appropriate behaviour when dealing with a request where a collection URI is sent without trailing slash would be either a regular response, with a Content-Location header, or a redirect response. As the first option involves a simplification of client-server interaction, I think it is a reasonable approach and therefore would like to propose a patch that implements it by means of adding the Content-Location header missing in the proposal discussed in this thread. As a side note, I don't get the rationale behind the requirement of a trailing slash in collection URIs. It is neither necessary for identification purposes nor it is recommended as a way to establish if a resource is a collection. It rather seems to be something like a remnant from an ancient age, where Hungarian notation, 8.3 filenames and other species flourished. I have found convenient a somewhat detailed rationale to properly illustrate the point, thanks for reading it all the way to here. Best regards, -- Dhionel Díaz Centro Nacional de Desarrollo e Investigación en Tecnologías Libres Ministerio del Poder Popular para Ciencia, Tecnología e Innovación
signature.asc
Description: OpenPGP digital signature
_______________________________________________ nginx-devel mailing list [email protected] http://mailman.nginx.org/mailman/listinfo/nginx-devel
