Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00]

Cyrus Daboo wrote:

(following up on ietf-http-wg@w3.org)

> Do we anticipate that MKCOL will also have the same problem as PUT? i.e. 
> do we have to have an 'ADDCOLLECTION' method to take care of that case?

That's a good question that I thought about as well (but forgot to add a 
reminder for). In this version, I tried to stick with 
terminology/features of base HTTP (where MKCOL doesn't exist).

> How is a client supposed to know to use ADDMEMBER as opposed to PUT? 
> Does it have to check OPTIONS each time before it creates a resource in 
> a new part of the URI hierarchy?

If it does have a name it can try the PUT which will fail; we could 
define a simple way to find out that it's supposed to use ADDMEMBER 
instead (such as a specific precondition name for DAV:error).

If it doesn't have a name it can try ADDMEMBER right away (which will 
fail if the server can't do it).

> Is there any reason why we can't simply define a new status code for a 
> PUT (or MKCOL) that results in the resource being renamed by the server? 
> e.g.:
> 
> PUT /calendar/evt1.ics HTTP/1.1
> Host: localhost
> ...
> 
> HTTP/1.1 2xx Created and Moved
> Location: /calendar/xyz123.ics

As far as I can tell, a server doing that wouldn't implement the 
specified PUT semantics anymore.

> Yes, this would probably break existing http clients doing a PUT, but 
> those clients are going to have problems anyway since the server will 
> rename the resource from under them anyway. What it does do is provide a 
> clear indication for clients that can understand this behaviour. What is 
> more this response code can be used on any method that creates resources 
> without the need to have separate new methods for this. e.g. there are 
> now a whole host of MKxxxx methods that may need the same treatment as 
> PUT. The same probably applies to MOVE and COPY too.

I think it needs to be discussed whether you need a 
"server-defines-the-URL" variant for all these methods. If that is 
indeed the case, I'd propose to use a optional extension (RFC2774) 
through which a client could explicitly state that that behaviour is 
acceptable.

Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Received on Tuesday, 15 February 2005 16:08:13 UTC