[Ietf-caldav] [Fwd: draft-reschke-http-addmember-00]
daboo at isamet.com
Tue Feb 15 07:50:20 PST 2005
--On February 15, 2005 1:00:02 PM +0100 Julian Reschke
<julian.reschke at gmx.de> wrote:
> recently different communities (caldav/groupdav, atompup (protocol
> part)) have been discussing how to use HTTP to author new resources when
> the URL namespace is completely server-controlled, thus PUT just doesn't
> fit well.
> A simple approach would be to define a new HTTP method which is *almost*
> like PUT, except that the server chooses the URL to create (and returns
> it in the Location header).
> I've submitted a first draft as "draft-reschke-http-addmember-00". Note
> that it also contains an appendix covering possible alternative
> Feedback appreciated,
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?
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?
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
HTTP/1.1 2xx Created and Moved
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.
More information about the Ietf-caldav