Re: Behavior of Requesting node on a 3XX response in the SOAP HTTP Binding

On Tue, Aug 09, 2005 at 10:16:05PM -0700, Anish Karmarkar wrote:
> Yves Lafon wrote:
> >On Mon, 8 Aug 2005, noah_mendelsohn@us.ibm.com wrote:
> >>If we want to support use of 303, then it seems to me that the MEP is
> >>still request/response and the WebMethod is still post.  I read this as:
> >>"You did a POST and the usual way to get the Response is that it comes
> >>right back.  In this case, you got a 303 telling you to pull the response
> >>using GET, >however it still is a response to a POST.<  So, I think 
> >>you're
> >>using a somewhat more elaborate means to complete the POST, not changing
> >>the overall intended method to GET."
> >
> >
> >It depends on how we model that. Currently in our spec, we have a 
> >mapping where every SOAP interaction over HTTP equals with one HTTP 
> >request (as the redirect put the state machine back in "init" state, 
> >with another URI). In this case, it will be modelled differently, as the 
> >GET can't be done at the init state ("requesting" state?)
> >
> 
> I quite agree with that.
> If our binding relied on the underlying transport (HTTP) after the 1st 
> request and said do what the HTTP spec says then we would be in a place 
> where we could say -- it is still a response to POST, and that more 
> elaborate means are being used to complete the POST. But we specifically 
> say that it goes back to the Init state with a new value of the property 
> "http://www.w3.org/2003/05/soap/mep/ImmediateDestination". As a state 
> machine, then the requester then has to do exactly what it did before 
> (using different value for the property 
> "http://www.w3.org/2003/05/soap/mep/ImmediateDestination").

Exactly right.

303 is basically an extended 202 in that the response message is an
intermediate one.  But it *is* a response message.  Trying to treat
the (possible) follow-on GET response as the "actual" POST response
only, IMO, presents an insufficiently general abstraction which is
guaranteed to leak when confronted with more general application
protocols like HTTP.

If it were me (and I expect I said this while the issue was under
discussion), I'd simply terminate the state machine after the first
response and expose the response metadata.

> >300 Multiple Choices is also interesting, as the automatic choice for a 
> >retry depends on the presence of a Location header, and choud be 
> >mentionned, 305 is pretty straightforward, so is 304 (even if in that 
> >case we don't have an explicit SOAP envelope back).
> >
> 
> I'm beginning to wonder if we have over specified things in our binding, 
> rather than saying do what the underlying transport say you must do.

I mostly agree, but wouldn't personally call it over-specification.
I consider it simply *bad* specification, brought about primarily
because of the (IMO) misguided quest to shield application developers
from the semantics of the underlying protocol ("protocol independence").

Cheers,

Mark.
-- 
Mark Baker.  Ottawa, Ontario, CANADA.          http://www.markbaker.ca
Coactus; Web-inspired integration strategies   http://www.coactus.com

Received on Wednesday, 10 August 2005 15:57:39 UTC