Do you have a question? Post it now! No Registration Necessary. Now with pictures!
- Posted on
- no history
- Christian Schmidt
March 2, 2004, 1:04 pm
rate this thread
ist it possible to mark a HTML-page not to be pushed into the browsers
history list (so that you can't go back i.e. via the Browsers Back-Button)?
May be there are some <META>-Tags for doing that?? Or some
The background is that I implemented a little Perl script for editing a
(very ) simple database. And I want to prevent that the user goes back
and recalls pages with earlier entries he made...
Is that possible via HTML ?
Thanks in advance
Re: no history
HTML is means to mark up information, it doesn't tell user-agents how to
implement user-agent features.
1. Don't try and break the back button (such as via meta redirects:
You should look to adding this support more robustly to your
1. Use a more restrictive caching regime (do this with HTTP headers, not
meta tags) so that going back in the user-agent history (hopefully)
makes fresh requests to the server and doesn't pull files out of the
cache, this isn't foolproof though.
2. Clearly indicate to the user that they should not go back and
indicate the consequences of doing so.
3. When a user updates the database add a timestamp indicating when the
database was last updated, and in each instance of an update form place
a hidden field with the same timestamp value in it. When the client
submits a form compare the timestamp in the submitted form data to the
timestamp in the database. If the form timestamp is the same as the
database timestamp it is safe to update the database as no other updates
have occurred between the time the client fetched the initial form
webpage and the time it was submitted. If the form timestamp is younger
than the database timestamp then the data has been updated in the
intervening period (either by someone else, or by the same client
submitting a form and the going back in their history to an older
version of the form). In this case send the submitted data back to the
client, repopulate the form as it was before submission and write out
the newer data as 'plain text' with an appropriate explanation so he or
she can see both what was submitted and what the database was updated
with. The user can then decide whether to quit now and keep the data as
it stands in the database, submit their original data again or edit
their submission to account for the changes. There are other ways to
implement this, but you get the idea. This third option provides a much
more robust mechanism.