Re: draft-reschke-http-addmember-00

My main concern is that because of the popularity of SOAP,
many/most implementations fall into category 2b (i.e., "clueless"),
so a resource will say that it supports the POST operation,
but will actually fail it with some kind of 4xx response
because it cannot parse the body, or in the worst case,
will successfully parse the body and execute some potentially
harmful SOAP operation that was never intended by the client
(the client just wanted a subsidiary whose content was that body
to be created).

I'm rather surprised that clueless (e.g., SOAP :-) implementations
would parse the body of an unknown method (e.g., ADDMEMBER)
and treat it as if it were a POST call.  I would have expected
SOAP implementations to limit themselves to parsing only POST bodies.
But Roy knows way more about that kind of thing than I do ... 

But even if a clueless implementation will try to parse the
body of an unknown method like ADDMEMBER, I assume it is very
unlikely that it would say that it supports the ADDMEMBER
method on that resource, so that at least would give the client
a way of avoiding the problem (i.e., by first asking the resource
if it supports the ADDMEMBER function, before attempting it).

Cheers,
Geoff 


Roy wrote on 02/17/2005 06:50:39 PM:
>
> 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
> 
>    http://www.w3.org/Protocols/HTTP/Methods/Post.html
> 
> 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.
> 
> ....Roy
> 
>