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

[Dhionel Dí­az]

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, 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.
[...]
> 
> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 897 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20131009/13717ed7/attachment.bin>