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, JulianReceived on Tuesday, 30 September 2008 16:58:28 GMT
This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:16 GMT