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

Hi Julian,

--On February 15, 2005 5:07:38 PM +0100 Julian Reschke 
<julian.reschke@gmx.de> wrote:

> 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).

I think this server behaviour will impact WebDAV too (at least in the 
CalDAV 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?
>
> 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 
the name.

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?
>> 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.

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.

-- 
Cyrus Daboo

Received on Tuesday, 15 February 2005 16:56:05 UTC