Search Support

Avoid support scams. We will never ask you to call or text a phone number or share personal information. Please report suspicious activity using the “Report Abuse” option.

Learn More

Wannan tattunawa ta zama daɗaɗɗiya. Yi sabuwar tambaya idan ka na bukatar taimako.

Firefox 29 back button will not return to previous form

  • 16 amsoshi
  • 84 sa na da wannan matsala
  • 1 view
  • Amsa ta ƙarshe daga klangan

more options

Previous screen is a form for searching and the results returned. Clicking on a "more info" button moves to the next screen and shows more info. The "back" button will not return to the previous screen, giving the message, "document no longer available".

Firefox is standard vanilla install. All other major browsers return properly to the previous screen. If this cannot be corrected, we will be forced to abandon FIrefox and recommend to our 46,000 customers to move to another browser, especially when using our website.

To duplicate this problem, go to www.mybfl.com/search.php, search for a book, and when displayed, click on the 'More Info' button. Clicking on the Firefox "back" button illustrates the problem.

Previous screen is a form for searching and the results returned. Clicking on a "more info" button moves to the next screen and shows more info. The "back" button will not return to the previous screen, giving the message, "document no longer available". Firefox is standard vanilla install. All other major browsers return properly to the previous screen. If this cannot be corrected, we will be forced to abandon FIrefox and recommend to our 46,000 customers to move to another browser, especially when using our website. To duplicate this problem, go to www.mybfl.com/search.php, search for a book, and when displayed, click on the 'More Info' button. Clicking on the Firefox "back" button illustrates the problem.

Mafitar da aka zaɓa

Yes, Firefox 32 is when this behavior began.

I just went in and checked Tools->Options->Override Automatic Cache Management and for the moment at least, the problem has disappeared.

Thanks, hope this solves the problem.

Karanta wannan amsa a matsayinta 👍 11

All Replies (16)

more options

This is caused by Firefox honoring the instructions of the page not to cache or store it, so every reload requires another request to the web server. (See attached screenshot)

There might be a way to override this using an add-on, but in the short run, the best strategy is to open the links in a new tab or new window using one of these methods:

  • Ctrl+click or middle-click (scroll wheel) => open in a new tab
  • Shift+click => open in a new window
  • right-click menu also has these options

An gyara daga jscher2000 - Support Volunteer

more options

Thank you for your response. If I understand you correctly, the problem is with our website's presentation to Firefox. How do we keep our website pages from instructing Firefox not to cache or store the page?

We are not aware of having provided that kind of instructions and we are not doing an https.

Thanks for your help.

more options

The home page (index.php) comes with the same headers, so it may not be limited to search results.*

I'm not an expert on this but I think there are three places to check:

(1) In your php scripts, look for any header() directives at the beginning of the file.

(2) In the root directory, look for an .htaccess file that may contain cache-control headers.

(3) Check httpd.conf for cache-control headers. This may not be accessible on shared hosting services.

* However, Firefox only displays that dialog if the page you're trying to go back to was generated by a POST request.

An gyara daga jscher2000 - Support Volunteer

more options

Here is the content of .htaccess:

  1. comment spam

ErrorDocument 503 "Temporarily unavailable" RewriteEngine on RewriteCond %{REQUEST_METHOD} POST RewriteCond %{REQUEST_URI} /email/log.php RewriteRule .* - [R=503,L]

It appears none on the above is relevant to anything other than when taking down a website for maintenance and returning a 503 to search engines.

All of our web pages have the same headers/trailers, ie:

require_once "std.php"

   <web page scripts>

require_once "trailer.php"

Moving from any page to another allows a return to the previous page using the Firefox "back" button unless the previous page contained a form (search, logon).

The problem seems to be the form on the previous page. It is as if Firefox is afraid it cannot safely fill in the form (ie, the page has not been saved "as is"), but which is actually what we want.

It does not matter what Firefox settings we could apply as we cannot tell all of our customers to whom we have recommended Firefox, "By the way, you have to make this setting to get it working like it used to work."

We need a way for our webpages to signal, "Yes, by all means cache and copy!"

We do not seem to have an httpd.conf file, but I will pursue the possibility of it affecting us with our hosting company.

Thanks, Jack

more options

Could you check inside std.php for any header() lines?

more options

Checking the httpd.conf file content, there are no caching instructions other than where to cache SSL data and for how long. Firefox seems to think there is a security problem by caching/copying the page.

How do we turn that off? What can we add to what file so Firefox treats pages with HTML forms like any other page?

more options

The error description does make it sound like a security issue, but since it is an HTTP page, it isn't really about security.

I'm pretty sure those headers are being sent by your web server; by default, Firefox is happy to cache pages generated by a POST, whether they are send over a regular connection or a secure connection.

One option might be to send headers instructing Firefox to cache the page for a certain amount of time, e.g., 60 minutes, to see whether that overrides the no-cache headers. I can't experiment with that at the moment, I would need to research/test it first.

more options

Nothing like "header()" in std.php or any other php script (I did a grep). The first lines of std.php are:

<meta name="google-site-verification" content="S-KAkQLVtW8mHkOuwlrU2y_x5_a39oPxiSitp99UzZQ"> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> 90) echo "<meta http-equiv="refresh" content="$Refresh">"; ?> <meta http-equiv="Lang" content="en"> <meta name="description" content="Books For Less - New and Used Books"> <meta name="keywords" content=""> <title>Atlanta's Largest Independent Bookseller</title> <meta name="description" content="Your Atlanta bookstore - buy, sell and trade new and used books in Gwinnett County, Suwanee, Buford, Lawrenceville, Sugar Hill, Alpharetta, Fulton County and the surrounding area. Textbooks, novels, bibles and more. Stop by today!"> <link rel="SHORTCUT ICON" href="www.mybfl.com/images/favicon.ico"> <style> [ bunch of style stuff ] </style> And, all the pages work except for the one that has the HTML form for searching on it. I tried the logon form page and it does move backward fine. So it is not necessarily a form thing. How do I send a header instructing Firefox to cache?

more options

I added the line:

<meta http-equiv="cache-control" content="cache, store, public" />

but still got:

Document Expired

This document is no longer available.

The requested document is not available in Firefox's cache.

   As a security precaution, Firefox does not automatically re-request sensitive documents.
   Click Try Again to re-request the document from the website.
more options

Yes, the important headers are sent first before the HTML document even starts. The std.php include and the meta tag cannot override them. The workaround will require some PHP code at the very top of search.php.

more options

What needs to be sent before the HTML headers and will it affect setting cookies?

more options

Cookies have their own header, expiration date, and so forth. Those are not affected by the page's cache settings.


Could you check the first response to this StackOverflow question: Setting up Expire Headers with PHP. It mentions the exact headers sent with your page as matching either of these settings:

session_cache_limiter = nocache -- in your PHP configuration
session_cache_limiter("nocache"); -- in your search.php script

If you have the second line in your script, you can remove it or edit it. If it's in your configuration file, the suggested override is to start your search.php script with a new line:

<?php
session_cache_limiter(false);

Does that work?


If you want to create global settings, this article sets out what to add to .htaccess -- except in your case, you would put php in the "2 hour" category:

http://www.askapache.com/hacking/speed-site-caching-cache-control.html

I haven't tried that myself.


If you need to send individual cache-control and expires headers from PHP for finer control, I haven't looked up the syntax, but I'm sure you can find it with some searches.

more options

Thank you very much. I tried adding the line:

session_cache_limiter(false);

to our std.php as the first php line, but that did not fix it.

I then pulled our php.ini file and found :

session.cache_limiter = nocache

and changed it to:

session.cache_limiter = public

and that immediately fixed it.

Thank you again. We can continue to recommend Firefox as the browser of choice!!

more options

This is caused by Firefox honoring the instructions of the page not to cache or store it, so every reload requires another request to the web server.


This is a big problem for me. I do a lot of online editing and often have to look back several pages to get some code/css I deleted on a previous page that didn't think I needed any longer or to fix a mistake that didn't crop up until several saves later. IE behaved this way which is a major reason I switched to firefox long ago.

Looking at my headers there is no expiration date set so firefox isn't exactly *honoring* any instructions, it's simply not caching by default even though I have firefox set to use the cache

We've implemented all the "anticache" instructions where we need them, the new firefox model is the inverse of what we actually need. PLEASE PLEASE cache by default like you used to or at least make this new behavior optional. I've lost several hours of work/code and css because of this new model.

Here's an example of my headers and as you'll see those no expiration instructions: http://mydomain/cgi-bin/mypage.cgi POST /cgi-bin/page.cgi HTTP/1.1 Host: www.mydomain.com User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:32.0) Gecko/20100101 Firefox/32.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Referer: http://www.mydomain.com/cgi-bin/mypage.cgi Cookie: __utma= Authorization: Basic xxxxxx== Connection: keep-alive Content-Type: application/x-www-form-urlencoded Content-Length: 6644 do=page&content=THEPOSTEDCONTENT HTTP/1.1 200 OK Date: Thu, 18 Sep 2014 17:44:45 GMT Server: Apache Vary: Accept-Encoding Content-Encoding: gzip Content-Length: 4743 Keep-Alive: timeout=15, max=100 Connection: Keep-Alive Content-Type: text/html; charset=ISO-8859-1

more options

Hi klangan, did you notice this issue starting with Firefox 32?

A user who has been investigating this in detail reports that when the cache is full Firefox will start displaying the Document Expired page, suggesting that Firefox's caching behavior has changed in Firefox 32. Related thread: Firefox 32 always gives "Document expired" every single time I hit the Back key to return to search results.

more options

Zaɓi Mafita

Yes, Firefox 32 is when this behavior began.

I just went in and checked Tools->Options->Override Automatic Cache Management and for the moment at least, the problem has disappeared.

Thanks, hope this solves the problem.