Re: Concern about status code 303 and resolution to Rec33

Mark Baker writes:

> My understanding is that 303 indicates "Ok, I've done the 
> [POST], but if you want the results ( i.e. what would normally 
> be returned on the POST response), you'll have to invoke GET on
> this other resource to get them".

An important clarification, thanks.   I think this gets to the crux of the 
matter.  If 303 reliably means: "I've seen and taken responsibility for 
acting on your POST, I've therefore applied the full SOAP processing 
model, but for whatever reason your response envelope or fault envelope 
can be retrieved from this other URI", then I agree the resolution 
proposed is OK.  If it means:  "I'm not sure I want to do your POST, but 
try a GET here and you'll find out something interesting", then I agree 
the resolution is basically OK.

Presuming it is indeed the former, maybe we should add to the part of the 
binding that handles responders clause along the following lines:

"Status code 303 MUST NOT be sent unless the request SOAP envelope has 
been processed according to the SOAP processing model and the SOAP 
response is to be made available by retrieval from the URI provided with 
the 303."

This would make clear that the MEP and the SOAP processing model MUST be 
honored, regardless of how many servers and URIs are involved in the 
conspiracy to make it so.  Does this make sense?

Thanks.
--------------------------------------
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/15/2005 11:19 PM
 
        To:     "noah_mendelsohn@us.ibm.com" <noah_mendelsohn@us.ibm.com>
        cc:     xml-dist-app@w3.org
        Subject:        Re: Concern about status code 303 and resolution 
to Rec33


Hi Noah,

On 11/15/05, noah_mendelsohn@us.ibm.com
<noah_mendelsohn@us.ibm.com > wrote:
> Significance/Action:
>
> The requested resource has moved and 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. The value of
> http://www.w3.org/2003/05/soap/features/web-method/Method
> is changed to "GET", the value of 
> http://www.w3.org/2003/05/soap/mep/OutboundMessage
> is set to null.
>
> Next Step:
> Init
>
> </ProposedText> 

This doesn't feel right to me.  The application has in many cases specfied
WebMethod=POST, and that is part of the requested semantic at the post
level.  Now the initial responding site is saying: "I can't do the 
operation you had in mind, but please go to this other URI and try a
completely different operation."

My understanding is that 303 indicates "Ok, I've done the [POST], but if 
you want the results ( i.e. what would normally be returned on the POST 
response), you'll have to invoke GET on this other resource to get them".

One possible exception might be if a 303 is returned from a GET.
Consulting RFC 2616 we find:

> 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.
>
> The different URI SHOULD be given by the Location
> field in the response. Unless the request method
> was HEAD, the entity of the response SHOULD 
> contain a short hypertext note with a hyperlink to
> the new URI(s).

On the one hand, that says that 303 is primarily for POST.  On the other
hand, it doesn't rule out GET, and it specifically mentions the case of 
HEAD which is somewhat similar to GET.  Insofar as we believe that 303 can
come back from a WebMethod=GET, then I have no objection to doing the
redirection.

AFAICT, a 303 on a GET would have the same (or very similar) meaning as a 
302. 

Regarding 301 handling the proposal says:

> As the redirect handling is done at the SOAP level, everything is OK. 

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 

Cheers,

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

Received on Wednesday, 16 November 2005 15:10:59 UTC