I know people like to avoid those, but get real: refreshing a failed
> POST ought to re-POST the data (that will fail again). You should really
> only redirect on success.

Agreed, it's a much bigger consideration on success than failure. But once
you figure out a good way of approaching the issue on success, I imagine
it'd be just as easily applicable on failure?


> Passing the message in the request parameter (suggested by Mark) doesn't
>> seem like the ideal solution, because (assuming a parameterized message
>> based on submitted POST values) you'd need to pass the actual message in
>> the
>> query string. Not only would you have an ugly URL, but also someone could
>> visit that page with their own message by changing the query string.
> 
> Oh, no! Someone could mount an XSS attack on themselves! :p

:) Good call - I guess the ugly URL would be the main reason here, if any.


> Is there an ideal way to tell servlet S (one way I can think of is request
>> attributes - anything else?) not to execute its filter when a redirect
>> has
>> been performed (i.e. to perform no further execution of its thread
>> because
>> the request has redirected away from it)? That way, am I correct to say
>> you
>> have a good solution - no race condition, no messages in query string,
>> and
>> you can use redirects as desired?
> 
> Um, <dispatcher>?

So would the following be a good way of approaching this using filter
mappings (where the filter is as described in the OP)?
- No filter on all servlets that can, upon success or failure, redirect to
another page
- Filters on all JSPs with a ${message} anywhere in their markup

In what ways could I use the dispatcher element to enhance the setup
further?

Thanks.
-- 
View this message in context: 
http://www.nabble.com/Race-condition-with-values-displayed-across-redirects-tf4565759.html#a13044760
Sent from the Tomcat - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to