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

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

From: Scott Lawrence <scott@skrb.org>
Date: Mon, 21 Feb 2005 21:56:29 -0500
To: Jamie Lokier <jamie@shareable.org>
Cc: Julian Reschke <julian.reschke@gmx.de>, Cyrus Daboo <daboo@isamet.com>, Mark Baker <distobj@acm.org>, "Roy T. Fielding" <fielding@gbiv.com>, WebDAV <w3c-dist-auth@w3.org>, HTTP Working Group <ietf-http-wg@w3.org>, CalDAV DevList <ietf-caldav@osafoundation.org>
Message-Id: <1109040989.3811.39.camel@localhost.localdomain>

On Mon, 2005-02-21 at 21:28 +0000, Jamie Lokier wrote:
> Scott Lawrence wrote:
> > > In which case I couldn't use the content-type of my actual request body 
> > > for the Content-Type request header, right?
> > 
> > I fear that I may have lost the thread of your comment... you cannot use
> > Content-Type to send anything _but_ the content type of your request
> > body.  
> Roy said that POST can take into account the request content type to
> decide the action that is taken.
> I believe Julian wants to "create resource" with an arbitrary content
> type - _without_ the content type having any effect on the action that
> is taken to create the resource.

But setting the content type of the resulting resource _is_ having an
effect !?!

The point that I think Roy and I have both failed to communicate is
this: POST does not in itself define what happens - the thing to which
the request is POSTed (identified by the full URL) makes that decision. 

That thing is free to use the URL, the content body, the time of day,
the phase of the moon, or whatever it wants to when deciding what to do
with the resource _and_you_get_to_choose_ because you are creating that
thing.  If you want to define how you use POST in such a way that you
say that the Content-Type of the body should be preserved in the new
resource you are adding to the server, that's fine.  If you want to post
an entity body in the request that encapsulates metadata about the
resource with the resource itself (as is done in rfc1867 form file
upload), that's fine too.  You already have what you need in POST -
defining a new method does not add any new capability - it just adds
ambiguity for the servers that don't know what it is (all intermediate
systems already know that POST is not idempotent and the response to it
can only be cached if the response so indicates - that's all you need).
Received on Tuesday, 22 February 2005 02:56:31 UTC

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