W3C home > Mailing lists > Public > xml-dist-app@w3.org > August 2005

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

From: Anish Karmarkar <Anish.Karmarkar@oracle.com>
Date: Tue, 09 Aug 2005 22:16:05 -0700
Message-ID: <42F98D95.1040409@oracle.com>
To: Yves Lafon <ylafon@w3.org>
CC: noah_mendelsohn@us.ibm.com, xml-dist-app@w3.org

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 

> 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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:27 UTC