if ( POST.equalsIgnoreCase( request.getMethod() ) )
{
StringBuffer buf = new StringBuffer();
buf.append( request.getRequestURI() );
buf.append( ? );
buf.append( request.getQueryString() );
response.sendRedirect( buf.toString() );
return;
}
You need to be careful
to debug :(
Dan.
-Original Message-
From: Neale [mailto:[EMAIL PROTECTED]]
Sent: 07 February 2003 09:01
To: Tomcat Users List
Subject: Re: response.sendRedirect() - is this allowed?
if ( POST.equalsIgnoreCase( request.getMethod() ) )
{
StringBuffer buf = new StringBuffer
Hello, Tomcat User's List,
There was some talk a few days ago about response.sendRedirect() after a POST
request being against the HTTP specification... is that really true? For example,
would this be a problem? IE and Netscape seem to do what I want!
// This is common trick I use after a
It isn't against the HTTP specification to sendRedirect (which in Tomcat
will result in a 302 response). It's just that very few (if any) browsers
actually implement the spec in this area. Most of them will respond by
doing a GET to the new URL, instead of a POST (which is what the RFC says to
// This is common trick I use after a form
submission to
// help make navigation easier for the user, and to
help
// avoid dual-submission of the same form.
//
Not clear - how is the second submission avoided?
if ( POST.equalsIgnoreCase( request.getMethod() )
)
{
StringBuffer buf
rf [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
// This is common trick I use after a form
submission to
// help make navigation easier for the user, and to
help
// avoid dual-submission of the same form.
//
Not clear - how is the second
Further to this, the W3 recognized the fact that many clients did not
adhere to the specification for 302 and 303, so they introduced 307 in HTTP
1.1--which was intended to be followed more strictly. The original method
must be used when following a re-direct, but when a non-idempotent method
