Front page not loaded from cache

PM me the url and I'll have a quick look later on today.

Philip.

I believe you have the solution (turn it off, enable css and js aggregation though in the performance/ cache section).

It's not really for me to guess why a module with 25 users that has not been developed since 2011 doesn't work, there's probably something on the page that sets a cookie or any one of the rewrite conditions that disable boost.

The differences between a windows and linux set up are so large that it requires a methodical comparison of everything, from the apache configuration, through to php. The thing that jumps out immediately is the difference between / and \ in the filesystems.

You don't say if the windows machine actually creates the cache.

Since you have control of the windows machine's configuration, then the first place to start would be going to the apache website and turning on the ReWrite log and the level (has to be in server configuration, not .htaccess), so that you can work out how the boost .htaccess rules are working and what the server is looking for in the cache. On any machine, finding _.html is easy (the front page for localhost) index_.html should also be easy. Your windows machine may have an entirely differing set of variables for DOCUMENT_ROOT and so need a very different .htaccess file.

What is helpful in a ReWrite Log is that it gets big fast so turn it up the loglevel slowly until you can find rules matching html where "pass through" is a matching correct rule, on a linux system this is like this (I've never seen it on windows)

192.168.1.80 - - [13/Apr/2013:09:42:46 +0100] [www.example.com/sid#7f35181a5230][rid#7f3511b9e028/initial/redir#1] (1) [perdir /var/www/drupal7/]  pass through /var/www/drupal7/cache/normal/www.example.com/drupal7/_.html

So you have a page in your cache/normal/domain.com directory like _.html ?
This cached page is never sent through to anonymous users ?
You have looked at the page source and there is no boost comment on the last line of the html?
There are no Rewrite Rules in your server configuration that like a virtual host file that could be overriding .htaccess?

Check that your boost rules are after RewriteBase in the .htaccess file.
If you are using the drupal redirection to either add or remove www like this

  # To redirect all users to access the site WITH the 'www.' prefix,
  # (http://example.com/... will be redirected to http://www.example.com/...)
  # uncomment the following:
  # RewriteCond %{HTTP_HOST} !^www\. [NC]
  # RewriteRule ^ http://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
  #
  # To redirect all users to access the site WITHOUT the 'www.' prefix,
  # (http://www.example.com/... will be redirected to http://example.com/...)
  # uncomment the following:
  # RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
  # RewriteRule ^ http://%1%{REQUEST_URI} [L,R=301]

that this is before the RewriteBase line and the boost code.

Check that your front page does not set a cookie by visiting it in firefox with firebug installed (this is the best option as the browser cache will be 100% disabled and sometimes because boost sends out cache headers the page may be generated but your browser will pay attention to the formerly received headers and show you the first non-boot version) , if you have a DRUPAL_UID cookie then boost will disable and any number of modules can set a cookie.

I can't see boost running anywhere on the site, nor can I find the cache/normal/nnua.com directory structure. Please provide further information. Also the server identifies itself as Tengine that I am unfamiliar with.

I've message you the admin username and password.Please take a look.
Best regards.

It's not a wise idea to just post details to public forums. Also we don't run a free fix it service here :)

The site's in Chinese with blocks made up of external links for a non-native speaker it would be next to impossible.

Then there is the legal side of having to break the server to fix it does not bear thinking about. The only thing I am sure about is that the drupal_uid cookie is not being set, but I would personally not access someone else's system change their .htaccess files, delve into their directory structure and check their virtual hosting configuration without any form of cover, plus I don't know the web server they are running.

Have you tried dev, regenerating the .htaccess file and then uncommenting the sections specific to apache 2.4.x ? what we have found is that there is a bug in some versions of apache and though it was patched some hosting services/ distributions are still using the buggy version.

Duplicate of #2078595: Apache 2.4 Won't Serve Frontpage Cache File (_.html) after 2.2 Upgrade