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: Thu, 17 Feb 2005 15:50:39 -0800
Message-Id: <d23b29d789b472835a75d0b2038b6ba0@gbiv.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>, Mark Baker <distobj@acm.org>, CalDAV DevList <ietf-caldav@osafoundation.org>, WebDAV <w3c-dist-auth@w3.org>
To: Julian Reschke <julian.reschke@gmx.de>

On Feb 17, 2005, at 5:54 AM, Julian Reschke wrote:
>>> 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  
> this proposal.
> 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  
> server-controlled?
> 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  
> (<http://greenbytes.de/tech/webdav/draft-reschke-http-addmember 
> -00.html#rfc.section.A.2>).

That is not allowed in HTTP.

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

That is allowed.

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

No, it isn't. The client must "discover" the server's URI somehow,
whether that be via hypertext, save under dialogs, or an atom link.
They are all equivalent discovery mechanisms.  When Atom does a POST
it will send a representation of an entry (which happens to be just
another resource).  When a generic HTTP client does a POST it will
send a representation of a resource.

The server receives a POST message targeting a URI and containing
a representation.  It can do one of three things: 1) deny the request
with method not allowed (or any other error); 2) treat all POSTs
as the same; or 3) decide, based on the URI alone or in combination
with the representation, how to process the request.

In all cases, the client can assume the addmember semantics of POST
without any interoperability issues.  It is the server's responsibility
to provide resource references to the client that match the actions
called for by whatever it is the client is doing, and even if the
client picks some random URI the server is more than capable of
providing an appropriate response.

Geoff asked what happens if the resource already supports POST
for some other purpose.  The answer is one of

    1) if the implementation supports the addmember purpose
       in addition to its other duties, it will return 201 Created;

    2) if the implementation does not allow subsidiary resources
       to be created, then

       a) if the implementation is written according to HTTP,
          it will return 415 Unsupported Media Type; or

       b) if the implementation is clueless, it will attempt to
          parse the media type that it expects and will fail with
          some form of 4xx response. [Note that this is the case
          whether the method is POST or ADDMEMBER -- clueless
          implementations do not check the method either.]

       c) if the implementation is totally ignorant of all things
          HTTP, it will respond with 200 and a friendly error message
          about how this site only works with MSIE 5 (again,
          regardless of the method used).

So, the answer to Geoff's question is a new method is not necessary
to distinguish one POST from another POST because this was already
considered by HTTP in 1992


and codified in RFC 1945, 2068, and 2616.  The reason it allows
the server so much leeway in its handling of the request is because
only the resource can determine, according to its own implementation
and purpose in life, the most appropriate way to store subsidiary
resources.  ANY other specification would assume that an HTTP
server is just another form of file server like FTP (which is not
its purpose in life, as I've explained a million times before).

If the client sends random unsafe requests to a Web server,
it will obtain randomly unsafe results regardless of the method
used.  If the server provides a URI as an authorable resource,
then POST to a collection has the semantics of adding a member
to that collection -- the semantics have not changed just because
webdav chose to ignore that feature of HTTP.

Received on Thursday, 17 February 2005 23:50:40 UTC

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