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

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

From: Roy T. Fielding <fielding@gbiv.com>
Date: Wed, 16 Feb 2005 17:45:46 -0800
Message-Id: <683a9392671e29b5f4fdfe7fd5089a25@gbiv.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>, CalDAV DevList <ietf-caldav@osafoundation.org>
To: Mark Baker <distobj@acm.org>

On Feb 16, 2005, at 4:53 AM, Mark Baker wrote:
> On Tue, Feb 15, 2005 at 03:02:46PM -0800, Roy T. Fielding wrote:
>> This feature of HTTP is already defined as
>>   POST + media-type ==> 201 + location
> I was thinking the same thing Roy, but a new method would have the
> advantage of improved visibility; an intermediary observing a POST/201
> interaction wouldn't see anything in the POST request which licensed it
> to interpret that request as an attempt to store state, whereas a new
> method would provide exactly that license.

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.

> 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.

>> The media type is more than
>> sufficient to distinguish this action from any other type of
>> misdirected POST,
> How so?

Because the target URI knows what type of collection it is and
how to process POST requests.

>   AFAICT, the media type could be anything.  Did I miss something
> in the I-D?

The I-D is irrelevant -- the feature already exists in RFC 2616
and all predecessors.

> But even if there was such a limitation, that seems a bit
> kludgy to me; could such an assumption be expected to hold for even the
> foreseeable future?  I wouldn't have thought so.

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.

Received on Thursday, 17 February 2005 01:45:47 UTC

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