W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2005

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

From: Stefan Eissing <stefan.eissing@greenbytes.de>
Date: Thu, 17 Feb 2005 13:58:58 +0100
Message-Id: <2844d19383802290887bde5ef6e22e11@greenbytes.de>
To: webdav <w3c-dist-auth@w3.org>

I think What Would Make The World A Better Place is a mechanism that 
generic clients can discover POST service points where they can persist 
new entities. There is nothing wrong with POST, it is just that a 
client cannot discover if and where a server supports that feature.

Atom solves this problem by embedding the POST service uri into the 
feed document. That is fine, but
a) has low reusablity for other protocols/applications
b) has no usability from the view of a generic client

  I think this is what Julian tries to address with ADDMEMBER, since 
this method will  be visible in an OPTIONS response. Alternatively, an 
OPTIONS reponse could carry an extra Header with the URI of such a POST 
service.

On second thought, this could also be nicely wrapped up inside a site 
description and the pointer to the site could be a header in an OPTIONS 
response. Then a small, extensible site description document (XML) 
could do the job nicely.

//Stefan

Am 17.02.2005 um 13:32 schrieb Geoffrey M Clemm:

>
> 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
>  >
>  >
Received on Thursday, 17 February 2005 12:59:33 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:07 GMT