There are a few points it is important to understand about writing applications for the World Wide Web.
The first is that whatever people may say, you have no control over what browsers people use to access your applications.
The second is that you have no control over how people choose to configure them.
The third is that you have no control over what software runs "between" the user's browser window and the code running on your server.
The fourth is that once you have served some information to some remote system, they have it, they can do what they want with it, and you can never take it back.
With all the above in mind, I hope you are not thinking that somehow preventing the "BACK" and "REFRESH" operations is any form of security or error-protection. All it will do is irritate people and motivate them to try and get round however you have done it. Can you tell us a little more about what you want to do this for. Lots of us have built successful web applications facing up to all these issues. We can probably suggest ways of producing an effective system which doesn't need to put heavy limits on what people do with their browsers. As a final side note, Rene Larsen's suggestions are a useful way of hinting that a page should alway be refreshed, but I would add that an expiry date of 0 is generally considered a slightly risky choice. There are cache systems out there which erroneously consider a value of 0 as the same as if the header is not present, so it's almost always better to put a positive, but definitely expired, value there (say Midnight, December 31, 1999).
Joined: Nov 08, 2001
People will find out that changing a person's browser will piss certain people off. There are some cases where the programmer has other options to figure out how to get around the problems. I post easy solutions to get to the answer. Most of these people's problems can be solved with cookies, but 1 line of code it better then 70 for people looking for a quick fix. If you looked at my back button page you will see that I tell them that it does not work, but who cares. Wish I could start a poll on this page saying if a person would rather get an anwser or a story about ethics. Shouldn't it be a person's choice to use a code and not another members?? Let them find out that disabling the back button will not bring back people. Maybe disabling the back button on a certain page will keep a person's browser from locking up. (This happened with a person with an applet. If the back button was pressed the browser locked up) Smile
Joined: Jan 07, 1999
Re-reading my post above, I hope it didn't come over as sarcastic or snide. I've probably been bitten by too many hard to use web sites and web applications, and sometimes I would just like the designers to stop and think a little before casually breaking the browser functionality we are all comfortable with. And thanks to Al Ian for the site link. When I do find myself needing to push that car, I know where I'll go for help !
My view is also closely tied to Franks. Most of the problems (in my opinion) tend to stem from people trying to build windows functionality into web-apps. A web app is not a window app, and the more you try to design it that way, the more trouble you'll run into. I also tend to take the hardline view, where you should develop applications that follow (and it never works perfectly, but you try) the original HTML and HTTP design. Thin clients, no client functionality, standards based, request/response etc etc. Go see my views on the new Flash mega-client in the JSP forum (coughing noises). Back/Forward/Refresh issues will always be a problem. It's always been my view (and always will be) that you can't reliably control this and nor should you. It encourages you to build further and further from the 'safety area', and soon you get to applications that only run on your machine... Dave