How to handle Back button, Browser Refresh problem at server side.

Question

Hi Friends,
How to handle Back button, Browser Refresh problem at server side in java?.
I am able to trace that,
request.getHeader("ACCEPT") is returning value- */*
when the browser was refreshed and returning different MIME types
for all other actions from browser.
I have doubt, will the above solution works always for all servers,browsers?.
Please also specify any solution to handle back button at server side?.
Thanks in Advance.
Venkat..

Answer 1

I'm sorry I don't think tht's the right solution for
the above question....
We must be aware that whatever scripting methdologies
we either javascript/vbscript would executed @
client(browser) side not @ server side....
Dud If U get a good solution keep me updated.....
THANKS & REGARDS,
RAHULMy dear friend ...
the bad news is that u simply cant disable or add any listener to the back button of the browser.
When u hit the back button of ur browser the URL gets re-executed. So in case u have a JSP then the history.forward() is the best solution. [only if the page doesnt get expired similar to secure https sites]
Now dont say that user can have javascript disabled ...those users will have a pretty touch time browsing websites since javascripts r used extensively by almost all websites.
But in case u have an action.do or servlet call then u need to manage it using a session variable since the request will be sent to the server rather than client.
For multiple form submittion issues read the following article in javaworld...
Client vs. server solutions
Different solutions can solve this multiple form submission situation. Some transactional sites simply warn the user to wait for a response after submitting and not to submit twice. More sophisticated solutions involve either client scripting or server programming.
In the client-only strategy, a flag is set on the first submission, and, from then on, the submit button is disabled based on this flag. While appropriate in some situations, this strategy is more or less browser dependent and not as dependable as server solutions.
For a server-based solution, the Synchronizer Token pattern (from Core J2EE Patterns) can be applied, which requires minimal contribution from the client side. The basic idea is to set a token in a session variable before returning a transactional page to the client. This page carries the token inside a hidden field. Upon submission, request processing first tests for the presence of a valid token in the request parameter by comparing it with the one registered in the session. If the token is valid, processing can continue normally, otherwise an alternate course of action is taken. After testing, the token resets to null to prevent subsequent submissions until a new token is saved in the session, which must be done at the appropriate time based on the desired application flow of control.
for more details refer :
http://www.javaworld.com/javaworld/javatips/jw-javatip136.html
Hope u got the idea.
FYI I have been using both these ideas in my credit card payment gateway project. This concept has worked really well.