I've configured Boost in accordance with the readme file. When I point my browser at the home page, a cached file (_.html) is created with the full HTML including the Boost footer. However, when I return to the home page, I receive a blank white page. Using view source, I see the following (which is different than the other white page issues that I've seen):

<?php

/**
 * @file
 * The PHP page that serves all page requests on a Drupal installation.
 *
 * The routines here dispatch control to the appropriate handler, which then
 * prints the appropriate page.
 *
 * All Drupal code is released under the GNU General Public License.
 * See COPYRIGHT.txt and LICENSE.txt.
 */

/**
 * Root directory of Drupal installation.
 */
define('DRUPAL_ROOT', getcwd());

require_once DRUPAL_ROOT . '/includes/bootstrap.inc';
drupal_bootstrap(DRUPAL_BOOTSTRAP_FULL);
menu_execute_active_handler();

This occurs in IE, Firefox, and Chrome. My .htaccess file is the following:

FileETag MTime Size
<FilesMatch "\.(html)(\.gz)?$">
  <IfModule mod_expires.c>
    ExpiresDefault A5
  </IfModule>
  <IfModule mod_headers.c>
    Header set Expires "Sun, 19 Nov 1978 05:00:00 GMT"
    Header unset Last-Modified
    Header append Vary Accept-Encoding
    Header set Cache-Control "no-store, no-cache, must-revalidate, post-check=0, pre-check=0"
    Header set X-Cached-By "Boost"
  </IfModule>
</FilesMatch>
<IfModule mod_mime.c>
  AddCharset utf-8 .html
  AddEncoding gzip .gz
</IfModule>
<FilesMatch "\.html(\.gz)?$">
  ForceType text/html
</FilesMatch>

SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006
Options None
Options +FollowSymLinks

I've tried this using Drupal 7.22 and 7.23. I've also reproduced it with a clean install of Drupal. I can access the cached file directly and it looks fine.

Cache pages for anonymous users is unchecked under performance. The server housing the Drupal instance has 1.7GB RAM and Drupal is the only significant application running on the server.

There are no watchdog entries when the white page shows up:

I've been trying to figure it out over the last couple of days. Any suggestions?

Thanks.

Matthew

CommentFileSizeAuthor
#7 apache.zip1.93 KBkerasai

Comments

Anonymous’s picture

Anonymous (not verified) commented
  • Turn off boost,
  • clear the cached file,
  • turn it on,
  • recreate the error,
  • turn it off.
  • Have a look through your web server error logs for a Fatal PHP error log at the end (otherwise you could be there all day).

A blank page is the default setting for a PHP crash and that should show you where the error occurred.

mhelm’s picture

mhelm commented

Thanks for the quick response! I tried out your steps and this is what was written to the apache error log --

[Sat Aug 24 16:41:24.199783 2013] [ssl:warn] [pid 7640] AH01909: RSA certificate configured for www.example.com:443 does NOT include an ID which matches the server name
[Sat Aug 24 16:41:24.507566 2013] [ssl:warn] [pid 7641] AH01909: RSA certificate configured for www.example.com:443 does NOT include an ID which matches the server name
[Sat Aug 24 16:41:24.507744 2013] [lbmethod_heartbeat:notice] [pid 7641] AH02282: No slotmem from mod_heartmonitor
[Sat Aug 24 16:41:24.601015 2013] [mpm_prefork:notice] [pid 7641] AH00163: Apache/2.4.4 (Unix) OpenSSL/1.0.1e PHP/5.4.13 configured -- resuming normal operations
[Sat Aug 24 16:41:24.601094 2013] [core:notice] [pid 7641] AH00094: Command line: '/opt/bitnami/apache2/bin/httpd -f /opt/bitnami/apache2/conf/httpd.conf'

Should I look at another log file or increase the logging level?

mhelm’s picture

mhelm commented

In doing a little more testing, this problem is only happening with the _.html file. If I navigate to a new page and a cached page is created and I return to that cached page, I see the rendered page fine with the Boost footer. However, any time that I do it with the _.html file, I encounter the error.

Anonymous’s picture

Anonymous (not verified) commented

Debugging will still be the same, you'll need to find something in either /etc/httpd/vhosts.d (fedora) or /etc/apache/sites-enabled (debian/ ubuntu), cpanel or whm have their own systems that generally rely on some variation on the domain name for the log file name.

kerasai’s picture

kerasai commented
Assigned: » Unassigned

I'm experiencing the same this as @mhelm in his original report and #3. I think this has to do with something weird in the way Apache is handling the rewrites.

  • Boost generated the cached page files as expected, for all pages including the home page.
  • Cached pages are served normally from the Boost cache except the home page.
  • The home page renders as "blank," which is actually just the source from index.html.

I've tried all sorts of things but unfortunately I haven't been able to figure out exactly how to handle it. Here are some notes.

I'm running Drupal 6.28 with Boost 6.x-1.21.

Not seeing anything in the Drupal, PHP, or Apache logs. Also not sure that there actually is an error, just a bug or configuration issue with some piece of the stack.

Tried setting RewriteBase, didn't have any effect.

If I change 

  RewriteCond %{DOCUMENT_ROOT}/cache/normal/%{SERVER_NAME}%{REQUEST_URI}_%{QUERY_STRING}\.html -s
  RewriteRule .* cache/normal/%{SERVER_NAME}%{REQUEST_URI}_%{QUERY_STRING}\.html [L,T=text/html]

to

  RewriteCond %{DOCUMENT_ROOT}/cache/normal/%{SERVER_NAME}%{REQUEST_URI}_%{QUERY_STRING}\.html -s
  RewriteRule .* cache/normal/%{SERVER_NAME}%{REQUEST_URI}_%{QUERY_STRING}\.html [L]

the home page renders, but is generated by Drupal--not served from the Boost cache file. This makes me think Apache somehow "misses" the cached file on the rewrite and tries to fire up the 404 ErrorDocument, which is index.php. When the type is specified as text/html the contents of index.php is rendered, when not specified it's interpreted as PHP and Drupal does its thing.

I've tried putting in a separate rule to catch the home page and route it to the appropriate cache file, no good. Checking for request uri of "/" it doesn't do anything, checking for request uri of "/index.php" it routes everything to the _.html cache file. I suppose I could get into parsing query string, but shifting bits like this hasn't been necessary on any other implementations I've run so that makes me hesitant to go down that road.

Not sure what to make of all this. Would appreciate any ideas.

Anonymous’s picture

Anonymous (not verified) commented
Status: Active » Postponed (maintainer needs more info)

I'd disable the modules you have installed one by one to check if there is anything that is causing this.

To get a temporarily working site, If other pages are caching correctly then to get a working site I would use the Cache specific pages and set it to ignore index.php.

It would be unlikely to be the rewrite rules feeding back through to index.php, since all the correctly generated pages have already been through that process, so it's something specific to the index page itself.

Off the top of my head then a likely explanation would be a redirect from example.com to www.example.com, which would generate no output. This could be tested by turning off boost and checking the headers through firebug and seeing if there is a 302 sent for one domain or the other and then confirming that the .htaccess is correctly configured with the redirect and boost sections in the correct place.

kerasai’s picture

kerasai commented
Status: Postponed (maintainer needs more info) » Active
StatusFileSize
new apache.zip1.93 KB

I've done some more testing, can't figure out exactly what the problem is, but I'm confident that it's Apache configuration of some type. I've got 2 VPS's with similar configurations from the same host, one has the problem the other does not. I've provided them with this information, so hopefully they'll have some useful input.

Please see the files attached below. It's effectively a static implementation of the Boost .htaccess action. If you'd like to try it out, unzip the contents of the zip into your webroot. It should look like this:

/path/to/webroot/apache/index.php

From there you can replicate (or not) the error by visiting the following URLs:

http://example.com/apache/ - (Will be "blank" if you're experiencing the issue)
http://example.com/apache/a - (should see "cached" page A)
http://example.com/apache/b - (should see "cached" page B)
http://example.com/apache/c - (should see "cached" page C)

Anonymous’s picture

Anonymous (not verified) commented

Have you done a basic 

phpinfo();

to check the settings for DOCUMENT_ROOT etc? Are the servers identical, for example is there a variation in something like the php.ini file for cgi.fix_path_info ? Did you test whether a redirect was taking place as requested ?

kerasai’s picture

kerasai commented

The only glaring difference I see in phpinfo() is that one is running PHP via mod_php and the other is cgi.

The environment that is acting up is the one running PHP as cgi and it has cgi.fix_pathinfo = 1. The other environment doesn't have the value.

However I don't see anything that leads me to think Apache would handle the rewrite differently. Please let me know if there's anything else specifically that you'd like me to review.

Observations:

  • Both had $_SERVER["DOCUMENT_ROOT"] set to the webroot of the respective installs.
  • The misbehaving environment has an additional parameter $_SERVER["CONTEXT_DOCUMENT_ROOT"] with the directory of the fcgi-bin.
  • In terms of the non-www to www redirect that you asked me to check, there's no redirect action happening. In the example I put together, the .htaccess logic is just the one RewriteCond that checks for the cached file and the RewriteRule that does the redirect.
  • What seems the most odd to me is that the RewriteCond works on both, and the RewriteRule seems to be "missing the destination" on one and not the other. Does that shine any light on what's going on?
Anonymous’s picture

Anonymous (not verified) commented
Assigned: Unassigned »

As you have a VPS you should be able to debug this better than a shared hosting environment. I have seen redirect blank pages before, the other item has been a cached PHP crash which is rarer but with this difference in PHP handling you should be able to to turn on the Rewrite log in your main apache configurations. But it is a little more complicated previously in Apache 2.2 you would use the RewriteLog and RewriteLogLevel directives.

http://httpd.apache.org/docs/2.2/mod/mod_rewrite.html#rewritelog

In apache 2.4 you'll need to use the loglevel as directed on these pages.

http://httpd.apache.org/docs/current/mod/mod_rewrite.html
http://httpd.apache.org/docs/current/mod/core.html#loglevel

These need to be initiated not in a .htaccess file but in the main server configuration and then the server needs a restart. (hence why shared hosting makes things difficult). What you would be looking for is why there is a miss. Also one thing that confuses me, is what the blank page is. the -s flag in the rewrite condition is very specific in that the file must be greater than zero in length, so what is in the blank file ?

The other interesting possibility is that there is a crash due to a lack of mod_mime (though strictly you should have a 500 server error displayed), caused by the T=text/html flag which seems to make a difference. In a terminal you may want to try

apachectl -t -D DUMP_MODULES

to check for differences in the modules for each installation as cgi based php cannot probe apache's loaded modules.

kerasai’s picture

kerasai commented

Thanks for the input @Philip_Clarke, I lack the expertise at that level of the stack to really attack this one. Also thanks for the diligent attention on this. I'm going to pass this info along to the host and continue poking at this. I'll let you know if/what we find.

Thanks again.