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

Roy T. Fielding wrote:
> ...
>> 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  
>> (< 
>> -00.html#rfc.section.A.2>).
> That is not allowed in HTTP.

Thanks for the clarification.

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

Sure. I didn't mean to imply otherwise.

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

How is it (the resource) supposed to distinguish?

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

I still have a hard time understanding what to learn from this. It seems 
that we're now discussing "when to define new HTTP methods" which is 
definitively an interesting topic...

1) If I understand you correctly, WebDAV should have said that POST to a 
WebDAV collection resource indeed is the operation I called ADDMEMBER. 
RFC2518 says in 

"Since by definition the actual function performed by POST is determined 
by the server and often depends on the particular resource, the behavior 
of POST when applied to collections cannot be meaningfully modified 
because it is largely undefined. Thus the semantics of POST are 
unmodified when applied to a collection."

It would be interesting to find out how the working group came to that 
decision (I don't remember seeing that discussion when I went through 
the archives some time ago; but I may have missed it).

2) RFC2518 introduces WebDAV collections as a new resource type (with a 
distinct creation method, MKCOL). How would a client use the POST method 
(as described above) to create a new collection then? In WebDAV, the 
only difference between a collection and a non-collection resource is 
containment; thus a WebDAV collection may respond to GET with any 
content type the server likes.

3) RFC3253 (DeltaV) defines "VERSION-CONTROL", which is a well-defined 
operation that puts a resource under version control (and may be applied 
to WebDAV collections as well). Of course that operation *could* have 
been defined using POST, but assuming POST to a WebDAV collection is the 
same as ADDMEMBER, how could I possible use POST to do something else 
then? So should RFC3253 have used POST instead? If the answer is "yes", 
how should it have resolved the conflict between the two differing 
semantics that are needed? If the solution is to use different URLs for 
POST, what would have been a good way to discover these URLs?



<green/>bytes GmbH -- -- tel:+492512807760

Received on Tuesday, 22 February 2005 19:19:57 UTC