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

On 15. Feb 2005, at 18:50 Uhr, Julian Reschke wrote:
> OK, I'll have to update the draft with a problem description :-).
>
> HTTP 2616 says in Section 9.6 
> (<http://greenbytes.de/tech/webdav/rfc2616.html#PUT>):
>
> "The PUT method requests that the enclosed entity be stored under the 
> supplied Request-URI. If the Request-URI refers to an already existing 
> resource, the enclosed entity SHOULD be considered as a modified 
> version of the one residing on the origin server. If the Request-URI 
> does not point to an existing resource, and that URI is capable of 
> being defined as a new resource by the requesting user agent, the 
> origin server can create the resource with that URI."
>
> That is, a server that stores the entity under a different URI than 
> the one provided by the client isn't doing what the client asked for.
>
> Therefore I propose that the client should explicitly state what it 
> wants. One approach is a new method, other approaches would be to 
> extend the PUT *request*.

I can't resist but to post it once again, sorry about that ;-):

http://greenbytes.de/tech/webdav/rfc2616.html#status.201
---snip---
10.2.2 201 Created

The request has been fulfilled and resulted in a new resource being 
created. The newly created resource can be referenced by the URI(s) 
returned in the entity of the response, with the most specific URI for 
the resource given by a Location header field.
...
---snap---

I still have the opinion that PUT+201+location+if-none-match as a way 
to create new items is in the core HTTP spec and that we don't need a 
new method nor a PUT extension for that.

IMHO the only thing which is really missing is a review on which WebDAV 
clients (few other support PUT?) have issues with a location header (or 
not).

best regards,
   Helge
-- 
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org

Received on Tuesday, 15 February 2005 21:43:57 UTC