Re: I-D Action:draft-reschke-webdav-post-00.txt

Cyrus Daboo wrote:
> 
> Hi Julian,
> 
> --On September 23, 2008 5:46:12 PM +0200 Julian Reschke 
> <julian.reschke@gmx.de> wrote:
> 
>>> "When a server supports WebDAV ACL [RFC3744], the DAV:bind privilege is
>>> required to be granted on the collection resource in which the new
>>> member resource is being created. If this privilege is denied or not
>>> present, the POST request MUST fail."
>>
>> Yes, although I'd move that into a "Relation to WebDAV ACL" section.
>>
>>> Another question: there is no restriction on what p:add-member URI can
>>> be? e.g. if I have the collection "/a/b/" can the p:add-member be
>>> another resource entirely, e.g. "/a/use-c-to-create-in-b/"? If this is
>>
>> I thought that was already clear; maybe I should have chosen a different
>> URI :-)
> 
> A couple of different examples would help make it clear.

<http://greenbytes.de/tech/webdav/draft-reschke-webdav-post-latest.html#rfc.issue.uri-format>:

       Note: the "Add-Member" URI can be the identical to the
       collection's URI (in which case the server just advertises the
       fact that POST to the WebDAV collection's URI is supported as
       defined within this specification).  But it can also be different
       from it, in which case it doesn't need to have any relation to the
       collection's URI.

       Given a collection URI of

        /docs/collection/

       all of the following URIs might occur as "Add-Member" URIs:

        /docs/collection/
        /docs/collection/;post
        /docs/collection;post/
        /docs/collection/&post
        /post-service?path=/collection/

       The remainder of the document uses the same format just for
       reasons of consistency; any other HTTP URI would do as well.

> ...
>> It seems that that kind of redirection would need a different mechanism.
>> Let's not make things more complicated than they need to be.
> 
> OK, then let's explicitly state that the add-member URI must not be on a 
> different server.

Speaking of which, it could also be considered a security problem (the 
ability of server A to cause clients to post to server B != A).

> ...

BR, Julian

Received on Tuesday, 30 September 2008 16:58:28 UTC