[Ietf-caldav] [Fwd: draft-reschke-http-addmember-00]
julian.reschke at gmx.de
Tue Feb 15 08:07:38 PST 2005
Cyrus Daboo wrote:
(following up on ietf-http-wg at 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?
> 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
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
More information about the Ietf-caldav