On Thursday 30 January 2003 11:34 am, Erik Price wrote:
> Daniel Brown wrote:
> > This was news to me too. But, from the horse's mouth:
>
> [...]
>
> > So, in theory, you should generate a 303 response if the request method
> > was POST, and the web page you're redirecting to should be retrieved with
> > a GET. But in practice, the web browser will do just what you expect it
> > to do if a 302 response is received.
>
> Hm... yes, in practice it works (currently that is how my app handles
> logins and it works in all browsers AFAIK), but at some point someone
> might implement the spec.  I always try to write in compliance of the
> spec, so what I'm wondering is how I can specify that the sendRedirect
> should use GET instead of the original method, which was POST.  (I seem
> to recall reading somewhere that sendRedirect uses the original method.)
>
>
> Erik

Section 10.3.4 of RFC 2616 (HTTP/1.1) addresses your problem:

<quote>
10.3.4 303 See Other

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

Note: Many pre-HTTP/1.1 user agents do not understand the 303 status. When 
interoperability with such clients is a concern, the 302 status code may be 
used instead, since most user agents react to a 302 response as described 
here for 303.
</quote>

Again, setStatus() and sendRedirect() in HttpServletRequest are your friends 
here.
I pulled the information above from rfc-editor.org.

Paul

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to