[Ietf-caldav] [Fwd: draft-reschke-http-addmember-00]
julian.reschke at gmx.de
Thu Feb 17 05:54:38 PST 2005
Roy T. Fielding wrote:
> POST is always an attempt to store state. It is the response that
> tells you whether the state has been stored. No POST can be
> interpreted by intermediaries, just as no "ADDMEMBER" can either.
> The system gains nothing from adding a new method. It might have
> gained something by not allowing HTML forms to use POST for safe
> actions, but that debate ended years ago. Creating new unsafe
> actions that do the same as what POST has already been defined
> to do is absurd.
Well, ADDMEMBER does not do the same thing. It's specced to do *one*
very specific thing, while POST basically allows the server to do
anything it likes.
>> Had HTTP a means for extending a method to declare this additional
>> expectation (as described in the draft's A.3 using RFC 2774), I agree
>> that POST + extension would be appropriate.
> It doesn't because it never needed it.
OK, let's step back and look at the situation that caused me to make
Two separate communities (CalDAV/GroupDav and Atompub) encountered the
same issue: what's the best way to create a new resource on an HTTP
server when I can't use PUT as the URI space may be entirely
1) CalDav's approach is: use PUT to an arbitrary member URI of the
container; then let the server automagically move it somewhere else, and
report that in the Location response header
2) Atom's approach is to use service URIs to which the client can POST,
and to discover these service URIs by parting entity (feed) bodies.
Somehow I have the (perhaps naive) wish that identical requirements
should lead to common protocol constructs.
1) Seems to break PUT semantics;
2) Is specific to Atom and not applicable to other protocols.
> The media type is not limited in HTTP and it is not equivalent
> to data format. The media type tells the recipient how to process
> the message given the method semantics. That is why sending the
> same data as "text/html" is functionally different from sending it
> as "text/plain" -- the two messages have different semantics.
> That will hold for anything compliant with HTTP/1.1.
So what would be your recommendation to the authors of CalDav and the
Atom Publishing Protocol? What's the best way to add a new member to a
container (storing the entity just like PUT, but letting the server
decide on the URI)?
Best regards, Julian
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
More information about the Ietf-caldav