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

Yves Lafon wrote:
> On Mon, 8 Aug 2005, noah_mendelsohn@us.ibm.com wrote:
> 
> [moving to xml-dist-app]
> 
>>> 'ImmediateDestination'). OR if a requester uses
>>> the GET method on receiving a 303 is it conformant
>>> to the SOAP HTTP binding as defined by SOAP 1.2,
>>> part 2: Adjunct. There seems to be conflict in
>>> trying to remain conformant to the HTTP spec and
>>> the SOAP HTTP binding when a 303 is received.
>>
>>
>>
>> I'm not an HTTP expert. but I note that RFC 2616 says:
>>
>>        "The response to the request can be found
>>        under a different URI and SHOULD be
>>        retrieved using a GET method on that
>>        resource. This method exists primarily to
>>        allow the output of a POST-activated
>>        script to redirect the user agent to a
>>        selected resource. The new URI is not a
>>        substitute reference for the originally
>>        requested resource. The 303 response MUST
>>        NOT be cached, but the response to the
>>        second (redirected) request might be
>>        cacheable."
>>
>> 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").

> 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.

> Our current definition for 3xx deals only with 301/302/307 (and 300 if 
> the Location header is present).
>

Received on Wednesday, 10 August 2005 05:16:18 UTC