-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
lb,
lightbulb432 wrote:
> 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
> - Fi
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 issu
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
lb,
lightbulb432 wrote:
> Redirects are used so that users don't encounter the resubmit warning by the
> browser when they refresh the page, and so that page refreshes don't result
> in the POST being resent to the server.
I know people like to avoid
Redirects are used so that users don't encounter the resubmit warning by the
browser when they refresh the page, and so that page refreshes don't result
in the POST being resent to the server. While it's a smaller consideration
when messages for invalid values are displayed, it's a bigger consider
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mark,
Mark Thomas wrote:
> lightbulb432 wrote:
>> I have a question about whether there is a race condition with the following
>> technique for displaying messages across redirects.
>
> Yes there is.
>
>> If you submit a form with an invalid value o
lightbulb432 wrote:
> I have a question about whether there is a race condition with the following
> technique for displaying messages across redirects.
Yes there is.
> If you submit a form with an invalid value on page P1 and the receiving
> servlet S redirects to another page P2, you'd like pag
