Refresh when user clicks back button

[morc]

hi,
is there any way to refresh the page when the user clicks back button?I
have a jsp page that i need to regerenate everything everytime the user
visits it.

its either that or i want to disable the back button so to force the
user to click a link so that hte page is refreshed.

If anyone knows how to refresh on back button click or disable the back
button please help me out.

thanks alot
-morc

[Thomas 'PointedEars' Lahn]

morc wrote:

is there any way to refresh the page when the user clicks back button?
No.
I have a jsp page that i need to regerenate everything everytime the user
visits it.
Tough luck.
its either that or i want to disable the back button so to force the
user to click a link so that hte page is refreshed.

You cannot, which is a Good Thing.
PointedEars

[Danny]

Check in jsp on how to send the client a HTTP HEADER of
"Cache-Control: no-store, no-cache, must-revalidate" for the page
which you wish it be refetched from the server.

Danny

[Randy Webb]

Thomas 'PointedEars' Lahn said the following on 2/10/2006 2:48 PM:

morc wrote:

is there any way to refresh the page when the user clicks back button?

No.

Are you now reversing course from your past behavior of believing that
cache headers can control caching behavior?

If JS is enabled, I *can* force a reload every time the page gets re-loaded.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[Thomas 'PointedEars' Lahn]

Randy Webb wrote:

Thomas 'PointedEars' Lahn said the following on 2/10/2006 2:48 PM:

morc wrote:

is there any way to refresh the page when the user clicks back button? No.

Are you now reversing course from your past behavior of believing
that cache headers can control caching behavior?

No, not at all. Not considering that the Cache-Control header would only
work for HTTP/1.1 clients, the following makes it clear that this header is
not a reliable way to force refresh on such an occasion.

,-[RFC2616: HTTP/1.1]
|
| 14.9 Cache-Control
|
| [...]
| Cache-Control = "Cache-Control" ":" 1#cache-directive
|
| cache-directive = cache-request-directive
| | cache-response-directive
| [...]
| cache-response-directive =
| "public" ; Section 14.9.1
| | "private" [ "=" <"> 1#field-name <"> ] ; Section 14.9.1
| | "no-cache" [ "=" <"> 1#field-name <"> ]; Section 14.9.1
| | "no-store" ; Section 14.9.2
| [...]
|
| 14.9.2 What May be Stored by Caches
|
| no-store
| The purpose of the no-store directive is to prevent the inadvertent
| release or retention of sensitive information (for example, on backup
| tapes). The no-store directive applies to the entire message, and MAY
| be sent either in a response or in a request. If sent in a request, a
| cache MUST NOT store any part of either this request or any response to
| it. If sent in a response, a cache MUST NOT store any part of either
| this response or the request that elicited it. This directive applies
| to both non- shared and shared caches. "MUST NOT store" in this context
| means that the cache MUST NOT intentionally store the information in
| non-volatile storage, and MUST make a best-effort attempt to remove the
| information from volatile storage as promptly as possible after
| forwarding it.
|
| Even when this directive is associated with a response, users might
| explicitly store such a response outside of the caching system (e.g.,
| with a "Save As" dialog). History buffers MAY store such responses as
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| part of their normal operation.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| The purpose of this directive is to meet the stated requirements of
| certain users and service authors who are concerned about accidental
| releases of information via unanticipated accesses to cache data
| structures. While the use of this directive might improve privacy in
^^^^^^^^^^^^^^^^^^^^^^^^^
| some cases, we caution that it is NOT in any way a reliable or
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| sufficient mechanism for ensuring privacy. In particular, malicious
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| or compromised caches might not recognize or obey this directive,
| and communications networks might be vulnerable to eavesdropping.
If JS is enabled, I *can* force a reload every time the page gets
re-loaded.

This was not about reloading. However (client-side) scripts are very likely
_not_ to be invoked when the Back feature is used. (Which is, for example,
the major drawback of disabling submit buttons after they were activated in
order to prevent repeated submission of identical data.)
HTH

PointedEars