show "webpage has expired" on back button

Question

What is the requirement for the browser to show the ubiquitous "this page has expired" message when the user hits the back button?

What are some user-friendly ways to prevent the user from using the back button in a webapp?

Answer 1

you need to set pragma-cache control option in HTTP headers: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9

However, from the usability point of view, this is discouraged approach to the matter. I strongly encourage you to look for other options.

ps: as proposed by Steve, redirection via GET is the proper way (or check page movement with JS).

Answer 2

Well, by default whenever you're dealing with a form POST, and then the user hits back and then refresh then they'll see the message indicating that the browser is resubmitting data. But if the page is set to expire immediately then they won't even have to hit refresh and they'll see the page has expired message when they hit back.

To avoid both messages there are a couple things to try:

1) Use a form GET instead. It depends on what you're doing but this isn't always a good solution as there are still size restrictions on a GET request. And the information is passed along in the querystring which isn't the most secure of options.

-- or --

2) Perform a server-side redirect to a different page after the form POST.

Looks like a similar question was answered here:

http://stackoverflow.com/questions/1054135/redirect-with-a-303-after-post-to-avoid-webpage-has-expired-will-it-work-if-t

As a third option one could prevent a user from going back in their browser at all. The only time I've felt a need to do this was to prevent them from doing something stupid such as paying twice. Although there are better server-side methods to handle that. If your site uses sessions then you can prevent them from paying twice by first disabling cache on the checkout page and setting it expire immediately. And then you can utilize a flag of some sort stored in a session which will actually change the behavior of the page if you go back to it.

Answer 3

I'm not sure if this is standard practice, but I typically solve this issue by not sending a Vary header for IE only. In Apache, you can put the following in httpd.conf:

BrowserMatch MSIE force-no-vary

According to the RFC:

The Vary field value indicates the set of request-header fields that fully determines, while the response is fresh, whether a cache is permitted to use the response to reply to a subsequent request without revalidation.

The practical effect is that when you go "back" to a POST, IE simply gets the page from the history cache. No request at all goes to the server side. I can see this clearly in HTTPWatch.

I would be interested to hear potential bad side-effects of this approach.