Page cached by Boost only displays if I clear my browser history

Does the page take an age to load ? if not then you could be getting a 304 returned (you can check if using firebug, safari or chrome) where basically the web server states "nothings changed" and it would display your cached copy, likewise with the other boost headers. If it is taking a long time to load, e.g. hitting the PHP and MySQL rather than a static page, then something in your history could be setting a cookie and you should use the same tools to check if a the cookie DRUPAL_UID is set, which means boost will not cache the page as it thinks you are not anonymous.

In firebug/ developer tools you need to find the setting to enable the cache (because your problem stems from a history wipe problem at first glance), then you reload the page and the header you should receive from the web server is http 304 rather than http 200. The other way is to look through your logs for your ip address and see if it sent a 304 or 200. It may help if you look for a fictional page on your server to get a 404 error so that then you can track your ip address and its requests.

sorry didn't read the first line of the last message, ANY value for DRUPAL_UID is considered as set.

The problem is that your site thinks it's not anonymous if you have that cookie set, logging out first and see if the cookie is unset. If not then you have a module somewhere that is against the module guidelines and is using the drupal session ID to send content. Most browsers also have the ability to clear a cookie based on a domain.

I can think of a couple of ways of testing this. a) logout and then reload the page and see if the DRUPAL_UID cookie has been set. b) search the module files for DRUPAL_UID and -1.

-1 seems very specific it appears that a module developer requires access to the drupal session functions and so has chosen an impossible user id, your cache is probably being generated by spider that don't accept cookies. Then come back and tell us what you found, also report it to the module developer that they should be setting their own unique cookie, and possible if it's a really major module then I will consider altering the core drupal code and .htaccess files.

You are welcome.

It will not be in Drupal Core, so it will be in sites/all/modules so if cpanel has an option the search those files, otherwise I would suggest FTP and a good text editor that can search a folder, or turning off the modules one at a time, logging out, checking, turning the module back on. At least the location of the modules should give you the names of the additional modules unless it is a block.

i is a possibility to change the .htaccess file but that is like supporting a module that is going against drupal core coding guidelines. I also suspect that the only people it effects would be those that log in then log out and become anonymous. This could be tested by you going to the home page, removing the DRUPAL_UID cookie, hitting reload and seeing if it created. Also the module should have "unset" the cookie, instead of setting it to -1, so it os 50-50 as to whether they need it set to some value to provide content to anonymous users.

It also doesn't solve the issue for lighttpd and nginx users, though I may be willing to discuss coding a temporary fix while you track down the module.

You can talk to the module creators and point out that DRUPAL_UID is solely supposed to be used for log in session ID's and permissions and that they need to add their own. You can highlight the problem with this issue because when you disabled the module and then logged out, you weren't able to get back in because the DRUPAL_UID was still set to -1, which is a pretty important bug "disable module / break website" ;-)