 Re: Refresh when user clicks back button
Randy Webb wrote:
[color=blue]
> Thomas 'PointedEars' Lahn said the following on 2/10/2006 2:48 PM:[color=green]
>> morc wrote:[color=darkred]
>>> is there any way to refresh the page when the user clicks back button?[/color]
>> No.[/color]
>
> Are you now reversing course from your past behavior of believing
> that cache headers can control caching behavior?[/color]
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.
[color=blue]
> If JS is enabled, I *can* force a reload every time the page gets
> re-loaded.[/color]
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
| 
