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: <noah_mendelsohn@us.ibm.com>
Date: Sat, 13 Aug 2005 09:20:32 -0400
To: Yves Lafon <ylafon@w3.org>
Cc: Anish Karmarkar <Anish.Karmarkar@oracle.com>, xml-dist-app@w3.org
Message-ID: <OFA1C37869.6C405F03-ON8525705B.005BF81B-8525705C.00494AE1@lotus.com>

Yves Lafon writes:

> It depends on how we model that.

Agreed.  I was speculating on one of the models that seemed to me to be 
worth a bit of consideration.  I think we're saying the same thing on 
that.  Thank you.

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------








Yves Lafon <ylafon@w3.org>
08/08/2005 05:42 PM
 
        To:     noah_mendelsohn@us.ibm.com
        cc:     Anish Karmarkar <Anish.Karmarkar@oracle.com>, 
xml-dist-app@w3.org
        Subject:        Re: Behavior of Requesting node on a 3XX response 
in the SOAP HTTP Binding


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?)

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

Our current definition for 3xx deals only with 301/302/307 (and 300 if the 

Location header is present).

-- 
Yves Lafon - W3C
"Baroula que barouleras, au tiéu toujou t'entourneras."
Received on Saturday, 13 August 2005 13:34:11 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:20 GMT