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

I believe the problem arises when you are trying to apply the
addmember function to a resource that already handles POST as meaning
"do the operation specifies in the body of the POST".
To use POST to perform an addmember to that resource, you would
need to have some special encoding of the addmember function in
the body of the POST.  But this special encoding only works on
resources that support that particular encoding for POST calls.
So that would mean that for a client to use POST to perform addmember,
it would need to know whether or not a resource already interprets
POST in a certain way, and then would need to know the encoding in
the body that would be understood by that resource as meaning "addmember".

I may be missing something obvious here (and if so, I'm counting on
Roy pointing it out :-), but if not, it seems that POST cannot be
defined to perform any particular operation, since it already is
being used by some resources to mean "perform the operation specified
in the body".

Cheers,
Geoff

Roy wrote on 02/17/2005 12:54:16 AM:
> 
> On Feb 16, 2005, at 9:46 AM, Jim Whitehead wrote:
> > RFC 2616 states:
> > "The actual function performed by the POST method is determined by the
> > server and is usually dependent on the Request-URI."
> >
> > From a client perspective this makes POST unreliable, and leads to the
> > desire to define a new method.
> 
> The action will either succeed or fail.  If it succeeds, the client
> will receive the exact same response from POST that it would have
> received from a new method.  If it fails, the client will receive
> the same potential set of failure responses as it might have from
> a new method.
> 
> The only way you could claim that a new method would be more reliable
> is if the client knows the exact implementation of the resource
> being requested, which is something that a client does not know
> with HTTP, and even if it did, it is far more likely that it will
> know how the server and all intermediaries will respond to the
> existing POST method than it could know about their response to
> a new method that has zero deployment.
> 
> ....Roy
> 
>