- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Tue, 15 Feb 2005 18:50:34 +0100
- To: Cyrus Daboo <daboo@isamet.com>
- CC: HTTP Working Group <ietf-http-wg@w3.org>, ietf-caldav@osafoundation.org
Cyrus Daboo wrote: > Hi Julian, > > --On February 15, 2005 5:51:29 PM +0100 Julian Reschke > <julian.reschke@gmx.de> wrote: > >> Yes, but protocols should not mandate a behaviour that directly >> contradicts it's definition in the base protocol -- *even* if it applies >> only to special clients. >> > > Well, I don't see this as 'contradicting' the base protocol, rather its > 'extending' it to clarify behaviour that some servers (perfectly > legitimately) may do. 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*. Best regards, Julian -- <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Tuesday, 15 February 2005 17:51:09 UTC