W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2009

Re: Last Calling webdav-post draft, Re: I-D Action:draft-reschke-webdav-post-02.txt

From: Julian Reschke <julian.reschke@gmx.de>
Date: Fri, 09 Jan 2009 17:33:22 +0100
Message-ID: <49677C52.5020405@gmx.de>
To: WebDAV <w3c-dist-auth@w3.org>
CC: Cyrus Daboo <cyrus@daboo.name>, Lisa Dusseault <lisa@osafoundation.org>


I received feedback from Cyrus in private mail, but follow up over here 
to that the discussion gets properly archived.

Cyrus Daboo wrote:
>> Hi Cyrus,
>> thanks for the feedback. More inline.
>>> In reviewing this for the write-up I have a couple of comments:
>>> 1) Section 3.2.1 - in the WebDAV spec I am writing I am following the
>>> "template" used in 4918 for definition of new WebDAV properties. I find
>>> using that promotes consistency and completeness in the definition. I
>>> would prefer that the definition in 3.2.1 follow that template.
>> I personally find that template sub-optimal because it leads to
>> repetition. Also the COPY/MOVE category should IMHO only be used when
>> it's a special case; otherwise we'll see lots of new behaviors made up
>> when they do not really make sense.
>> In this particular case, though, I'll have to add a statement that the
>> property is protected.
>>> From an implementation standpoint I find it useful to know what should 
> happen in a COPY/MOVE, though for the most part for live properties it 
> is not really relevant.

For now I just have added the statement that the property is protected 
The behavior for COPY/MOVE IMHO directly follows from its semantics, the 
same was other most live properties happen to behave.

>>> 4) Section 8 - given the stated security concern of an attacker tricking
>>> a client to use add-member on a server not supporting it, wouldn't it be
>>> better for a server to explicitly identify support for this extension
>>> via the DAV header? That way clients know from that whether the
>>> add-member property will be valid or not. I generally prefer advertising
>>> capabilities up-front like this rather than requiring clients to probe
>>> the server in some fashion to see what is supported. Given that this is
>>> a security concern I think being explicit about support for the
>>> extension would be good.
>> I'm not a big fan of adding new compliance classes when they aren't
>> absolutely needed; in particular because it means another round trip (the
>> classes can vary per resource after all).
> How about adding:
> "When retrieving the DAV:add-member property on a collection resource, 
> clients MUST also retrieve the DAV:supported-live-property-set property 
> and verify that the DAV:add-member property is listed there. If 
> DAV:add-member is not listed in DAV:supported-live-property-set, then 
> clients MUST NOT use any DAV:add-member value as the target of a POST 
> request to create a new resource."

Actually, the Security Considerations already say:

"In addition, on servers that do not support this specification, a 
malevolent user could set the DAV:add-member URI as a custom property, 
tricking other users to post content to an entirely different URI. 
Clients can protect themselves against this scenario by

     * not following DAV:add-member URIs to different servers, and/or
     * verifying that the DAV:add-member property is indeed a live 
property (this can be achieved by testing the 
DAV:supported-live-property-set property, or by checking whether 
DAV:add-member is returned upon PROPFIND/allprop)." -- 

> ...
>>> 5) MKCOL - in Section 4 you state that servers may restrict use of MKCOL
>>> in a collection. But it is not clear how POST + add-member can be used
>>> as a substitute for MKCOL. i.e., what would the POST body look like for
>>> creation of a server-named collection?
>> There isn't any. If we leave things they are we should state that this is
>> a restriction.
>>> 6) Section 4 - same issue as for MKCOL for COPY/MOVE. If a server
>>> refuses a COPY/MOVE that creates a new resource, how does the client
>>> actually use DAV:add-member to trigger the equivalent behavior? The
>>> client should not need to send the data of the original resource in the
>>> POST in order to create the new one. That certainly wouldn't work when a
>>> collection is being moved. So what should happen here?
>> Again: out of scope.
> OK, then I suggest you remove MKCOL, COPY and MOVE from Section 4. 
> Perhaps even be explicit up front that this extension only deals with 
> the case of new resource (non-collection) creation using PUT and that 
> MKCOL, COPY and MOVE behavior is not defined here (though could be 
> defined by a later extension if there is demand for it).

I have added prose in two places clarifying that this can be used in 
place for PUT, but not the other methods. I've left the other text 
intact, as the precondition that is defined here indeed applies to all 
these methods: 

> ...

Best regards, Julian
Received on Friday, 9 January 2009 16:34:09 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:37 UTC