[Ietf-caldav] [Fwd: draft-reschke-http-addmember-00]
daboo at isamet.com
Tue Feb 15 08:25:09 PST 2005
--On February 15, 2005 5:07:38 PM +0100 Julian Reschke
<julian.reschke at gmx.de> wrote:
> 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).
I think this server behaviour will impact WebDAV too (at least in the
>> 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).
But the PUT does not fail. It succeeds, however the server immediately
'moves' the resource to a new location and the client does not know about
that. Alternatively the server would return a new '4xx Try ADDMEMBER'
response code - but I would argue my proposal for a '2xx Created and Moved'
is a better solution as it only needs one roundtrip.
> If it doesn't have a name it can try ADDMEMBER right away (which will
> fail if the server can't do it).
There are actually two problems here:
1) Servers that cannot accept arbitrary client-generated URIs on new
resources and need to 'rename' those to something that is internally
consistent with its own policies.
2) Clients that 'dont care' about the name of the resource being created -
they just want it to be unique and leave it up to the server to generate
I thought we were only trying to solve (1), but your ADDMEMBER proposal
also solves (2). However, (2) is also relevant for MKxxx, MOVE and COPY and
we don't have those solved.
>> 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.
One could argue that the types of server we are talking about don't
implement PUT semantics anyway, by virtue of the fact that they move the
resource as soon as it is created without telling the client. So '2xx
Created and Moved' is no worse than the current state for existing clients
- but it is better for clients that are 'aware' of this behaviour.
>> 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.
I think it would be reasonable for a client request to contain a header
that indicates it knows how to handle '2xx Created and Moved' which will
then allow the server to generate that response code if it needs to.
More information about the Ietf-caldav