Refresh when user clicks back button

Discussion in 'Javascript' started by morc, Feb 10, 2006.

  1. morc

    morc Guest

    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
     
    morc, Feb 10, 2006
    #1
    1. Advertisements

  2. Tough luck.
    You cannot, which is a Good Thing.


    PointedEars
     
    Thomas 'PointedEars' Lahn, Feb 10, 2006
    #2
    1. Advertisements

  3. morc

    Danny Guest

    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
     
    Danny, Feb 11, 2006
    #3
  4. morc

    Randy Webb Guest

    Thomas 'PointedEars' Lahn said the following on 2/10/2006 2:48 PM:
    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 Webb, Feb 14, 2006
    #4
  5. 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.
    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
     
    Thomas 'PointedEars' Lahn, Feb 14, 2006
    #5
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.