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