- From: <noah_mendelsohn@us.ibm.com>
- Date: Wed, 7 Dec 2005 10:49:43 -0500
- To: Mark Baker <distobj@acm.org>
- Cc: mbaker@gmail.com, xml-dist-app@w3.org, Yves Lafon <ylafon@w3.org>
Mark Baker writes: > Unfortunately it's not the role of the service to declare that > it can be trusted 8-); that's something only the human > operating the client can decide, because they - not the service > doing the redirection - have to take responsibility for the > implications of the unsafe message.... hence the need to > verify with them. I dont' think it's directly the service that says "trust my redirections", it's the human who chooses to install "client" software that's configured to say "if you get a redirect that matches [your favorite predicate involving ports, endpointrefs, QNames, whatever], then assume that redirections are to be trusted. If the human chooses to base that predicate on a reading of the "instruction book" for some particular service, so be it. That's his or her choice. I think the intent of the proposed spec text is fine as it stands. -------------------------------------- Noah Mendelsohn IBM Corporation One Rogers Street Cambridge, MA 02142 1-617-693-4036 -------------------------------------- Mark Baker <distobj@acm.org> Sent by: mbaker@gmail.com 11/16/05 10:30 PM To: Yves Lafon <ylafon@w3.org> cc: "noah_mendelsohn@us.ibm.com" <noah_mendelsohn@us.ibm.com>, xml-dist-app@w3.org Subject: Re: Concern about status code 303 and resolution to Rec33 Thanks for bringing that to my attention Yves; it apparently evaded my radar. On 11/16/05, Yves Lafon <ylafon@w3.org> wrote: > On Tue, 15 Nov 2005, Mark Baker wrote: > > >> I can see why it's OK per the HTTP recommendation. > >> > > > > I don't think it is, as I mentioned before; > > http://lists.w3.org/Archives/Public/xml-dist-app/2005Oct/0006.html > > > > And I replied at > http://lists.w3.org/Archives/Public/xml-dist-app/2005Oct/0010.html :) > Are you happy with the amended text? > Thanks, > > In that message you wrote (sorry for the formatting); >> Keep in mind that all agents are "user agents", in that they act on >> behalf of some human, somewhere. Whether that relationship is >up-close > >Are you sure that they act on behalf of humans? always? In the case of >automatic selection of a Web Service to accomplish one task, it's more >difficult to go back to the human originator of the request. Yes, it's more difficult, but outside of Skynet[1] (8-), all software operates under the authority of a human, so I think it's required. [1] http://en.wikipedia.org/wiki/Skynet >I agree that redirecting unsafe HTTP methods requires confirmation, ><sublimnal>use GET when you can!</subliminal> and that the >confirmation >can't happen directly at the SOAP binding level. >However, if you have a description of a service that explicitely says >"you >might get redirected to this set of URIs, and it is OK", then, as you >already trusted the service definition to craft your SOAP message, you >can >also assume that automatic redirection is at the same safeness level. Unfortunately it's not the role of the service to declare that it can be trusted 8-); that's something only the human operating the client can decide, because they - not the service doing the redirection - have to take responsibility for the implications of the unsafe message.... hence the need to verify with them. >So let's amend the proposal for the 301/302/307 redirections: > >Status Code: >301,302,307 > >Reason phrase: >"Redirect" > >Significance/Action: > >The requested resource has moved. >In the case of unsafe HTTP method, like POST or PUT, explicit >confirmation >is required before proceeding as follow. I assume you mean "is required before resending the message to the new URI"? >In the case of a safe method, like GET, or if the redirection has been >approved, the HTTP request SHOULD be retried using the URI carried >in the >associated Location header field as the new value for the >http://www.w3.org/2003/05/soap/mep/ImmediateDestination property. Well, it does seem like it's just repeating what's in the HTTP specification. But at least it's consistent, AFAICT. So if the group's ok with doing that, then it's fine by me too. Thanks. Mark
Received on Wednesday, 7 December 2005 15:49:54 UTC