Concern about status code 303 and resolution to Rec33

I infer that the WG has been kind enough to try and wait for a reading 
from me before finalizing the Issue Rec33 resolution proposed at [1]. 
That's much appreciated, thank you.  I should say that Chris Ferris and I 
have been traveling a lot and have had trouble finding each other to 
coordinate a unified IBM position.  So, here is my personal response, 
which may or may not yet be in sync with his.

I have at leats one significant concern, which has to do with the handling 
of 303 status codes.  As the proposal says:

> 303 is different as it changes the kind of HTTP request to a 
> GET, and also there is no longer an entity body sent in the 
> subsequent request.

Right.

> The good thing is that the state machine is the same regardless
> of the MEP defined, so we are not running in the issue of 
> having to switch state machine there, which is what I feard originally.

> So the suggested course of action for 303 is to
> add an entry in table 17
> 
> <ProposedText>
> 
> Status Code:
> 303
> 
> Reason Phrase:
> See Other
> 
> 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."  In the case where the user agent is a 
browser I can understand how deferring to the server may be acceptable. In 
this case, we're using SOAP, and we have a situation where the requested 
operation can't be executed.  So, I would think that the right thing to do 
would be to generate a binding-dependent fault indicating that the 
operation could not be performed. 

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.  Unless someone can explain why it's OK, I am not comfortable 
changing the method on a redirect. 

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 suppose that as long 
as we warn people that this will happen, it may be OK.  I can't say I have 
a warm feeling about it.  Are there any transport level security issues we 
should be considering, which I suppose is a roundabout way of asking 
whether we need to worry about those who might go beyond the Rec as 
strictly written and use it with HTTPS in place of HTTP.  Anyway, I won't 
slow down the group on this latter point if everyone else is in agreement 
that there's no problem.  I do want to better understand the 303 case.

Thank you.

Noah

[1] http://lists.w3.org/Archives/Public/xml-dist-app/2005Oct/0005.html
[2] http://www.ietf.org/rfc/rfc2616.txt

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

Received on Wednesday, 16 November 2005 03:01:49 UTC