W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2005

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

From: Julian Reschke <julian.reschke@gmx.de>
Date: Tue, 15 Feb 2005 18:50:34 +0100
Message-ID: <4212366A.5010003@gmx.de>
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 

"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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:13:26 UTC