Apache 2.4 Won't Serve Frontpage Cache File (_.html) after 2.2 Upgrade

I've encountered the same problem - front page cached but served as blank - with the current versions of Boost for both D6 and D7 running on Apache 2.4.6 with PHP via FastCGI. I've worked around it for now by inserting special handling for the front page in the Boost .htaccess rules, but I'd love to see a supported solution that I could roll out to my many shared-hosting clients. As their hosts may upgrade Apache at any time, this is a pretty ugly problem: their front pages could disappear without warning.

Thanks for the quick response, Philip. A bit more information: I've now moved two D6 and two D7 sites to the same environment (Apache 2.4.6, PHP 5.3.27 via FastCGI, Ubuntu host). One D6 and one D7 site presented a blank front page to anonymous users, and the other two sites simply served a non-cached page. I haven't yet identified the cause of the differing behavior, as Boost was configured identically on the two D6 sites and the two D7 sites.

I thought I had a usable manual .htaccess workaround for the front page for both, but it's turned out to be unreliable on the D6 sites and I haven't yet determined why. It does seem to be reliable on D7. (It just checks REQUEST_URI for /index.php and serves the _.html page for it.)

In answer to your questions:

When it serves a blank page, is there any html content at all ?

On both D6 and D7, what's served is the contents of index.php in plain text (without PHP interpretation).

Any relevant headers because we have to negate that there is an issue like content being zipped and sent with the wrong filesize (has happened before with chrome).

The headers were the same on both systems and looked normal to me. Their lengths were correct for the data served. Example from D6:

Date: Fri, 20 Sep 2013 06:02:53 GMT
Server: Apache/2.4.6
Vary: Host
Last-Modified: Wed, 16 Jan 2013 21:09:10 GMT
Etag: "39b-4d36e4a1b2980"
Accept-Ranges: bytes
Content-Length: 923
Content-Type: text/html

200 OK

Are there any log indications to state that the cached page has been served, previously the logs seem to indicate that something in 2.4 is ignoring the boost rules for / and reverting to the drupal set and going to index.php

No. So far as I can tell, the front page cache is created correctly, but it's not served by the Boost .htaccess rules because the value of REQUEST_URI isn't '/' (as before), but '/index.php'.

can _.html be accessed directly by typing the URL into the browser and going through cache/normal ?

Yes, it can.

I don't know how much trouble this would be to manage DB-wise, but would it be possible to special-case the front page and cache two copies of it, one as _.html (as before) and one as index.php_.html? This might be a fairly simple way to accommodate both older and newer Apache behaviors.

I'm indeed using 12.04.2 LTS; these are all Pair Networks accounts. I moved another two sites (one D6, one D7) to that environment this evening, and both exhibited the same problem. FWIW, no other white-screen issues or other problems have been observed with any of these installations.

So apache 2.4 on ubuntu 12.04.2, any idea which PPA ? or was it built for you ?

These are standard shared hosting accounts in their server pool, so everything was pre-built.

Shell access, yes, but don't seem to have it in my path or be able to find it in the likely places. Where would Ubuntu normally put this? My admin experience has been on CentOS.

Welcome to Ubuntu 12.04.2 LTS (GNU/Linux 3.2.0-51-generic x86_64)

 * Documentation:  https://help.ubuntu.com/
inoyes@www2:~$ apache2ctl -M
The program 'apache2ctl' is currently not installed.  To run 'apache2ctl' please ask your administrator to install the package 'apache2.2-common'

Thanks for your research on this.

FWIW, the following .htaccess changes allow my D7 sites to cache the front page via Boost. D6 needs additional work, probably due to the difference in how it handles page routing.

### BOOST START ###

  # Allow for alt paths to be set via htaccess rules; allows for cached variants (future mobile support)
  RewriteRule .* - [E=boostpath:normal]

  # Caching for anonymous users
  # Skip boost IF not get request OR uri has wrong dir OR cookie is set OR request came from this server OR https request
  RewriteCond %{REQUEST_METHOD} !^(GET|HEAD)$ [OR]
  RewriteCond %{REQUEST_URI} (^/(admin|cache|misc|modules|sites|system|openid|themes|node/add|comment/reply))|(/(edit|user|user/(login|password|register))$) [OR]
  RewriteCond %{HTTPS} on [OR]
  RewriteCond %{HTTP_COOKIE} DRUPAL_UID [OR]
  RewriteCond %{ENV:REDIRECT_STATUS} 200
  RewriteRule .* - [S=5]  # Added 2 to this value to accommodate added rules for Apache 2.4

  # GZIP
  RewriteCond %{HTTP:Accept-encoding} !gzip
  RewriteRule .* - [S=2]  # Added 1 to this value to accommodate added rule for Apache 2.4
  RewriteCond %{DOCUMENT_ROOT}/cache/%{ENV:boostpath}/%{HTTP_HOST}%{REQUEST_URI}_%{QUERY_STRING}\.html -s
  RewriteRule .* cache/%{ENV:boostpath}/%{HTTP_HOST}%{REQUEST_URI}_%{QUERY_STRING}\.html [L,T=text/html,E=no-gzip:1]
  # Special handling for front page for Apache 2.4
  RewriteCond %{REQUEST_URI} ^/index\.php$
  RewriteCond %{DOCUMENT_ROOT}/cache/%{ENV:boostpath}/%{HTTP_HOST}/\_%{QUERY_STRING}\.html\.gz -s
  RewriteRule .* cache/%{ENV:boostpath}/%{HTTP_HOST}/\_%{QUERY_STRING}\.html\.gz [L,T=text/html,E=no-gzip:1]

  # NORMAL
  RewriteCond %{DOCUMENT_ROOT}/cache/%{ENV:boostpath}/%{HTTP_HOST}%{REQUEST_URI}_%{QUERY_STRING}\.html -s
  RewriteRule .* cache/%{ENV:boostpath}/%{HTTP_HOST}%{REQUEST_URI}_%{QUERY_STRING}\.html [L,T=text/html]
  # Special handling for front page for Apache 2.4
  RewriteCond %{REQUEST_URI} ^/index\.php$
  RewriteCond %{DOCUMENT_ROOT}/cache/%{ENV:boostpath}/%{HTTP_HOST}/\_%{QUERY_STRING}\.html -s
  RewriteRule .* cache/%{ENV:boostpath}/%{HTTP_HOST}/\_%{QUERY_STRING}\.html [L,T=text/html]

  ### BOOST END ###

This appears to be working OK for me, though there may be failure cases or side effects that I haven't observed yet.

Does your set up generate _.html in the cache ?

Yes, it does. Boost will subsequently serve the file.

also what happens with

http://www.example.com/?x=y

_x=y.html is written to the cache and subsequently served by Boost.

if drupal is not in / but in a subdirectory like /drupal [...]

Thanks. I hadn't tested that case.

Great, thanks.

Have you had any luck with a similar workaround for D6?

Thanks jerry, that fix is working for me.

Related links

Philip, have you had time to make any progress on a D6 workaround and/or a D7 patch for this problem yet?

After debugging the same problem for 3 hours, I finally found this issue. Thank's a lot jerry, your fix works for me as well! :)

OK, I've finally had both time and motivation to return to this issue, and I have a workaround for D6 as well. It's essentially the same as the one presented in #25 for D7 with the paths adjusted for D6, but with one obscure but necessary change: a slash has been added prior to the argument list in the standard redirect rule following the Boost section:

  ### BOOST START ###

  # Gzip Cookie Test
  RewriteRule ^(.*)boost-gzip-cookie-test\.html cache/perm/boost-gzip-cookie-test\.html\.gz [L,T=text/html,E=no-gzip:1]

  # GZIP - Cached css & js files
  RewriteCond %{HTTP_COOKIE} !(boost-gzip)
  RewriteCond %{HTTP:Accept-encoding} !gzip
  RewriteRule .* - [S=2]
  RewriteCond %{DOCUMENT_ROOT}/cache/perm/%{HTTP_HOST}%{REQUEST_URI}_\.css\.gz -s
  RewriteRule .* cache/perm/%{HTTP_HOST}%{REQUEST_URI}_\.css\.gz [L,QSA,T=text/css,E=no-gzip:1]
  RewriteCond %{DOCUMENT_ROOT}/cache/perm/%{HTTP_HOST}%{REQUEST_URI}_\.js\.gz -s
  RewriteRule .* cache/perm/%{HTTP_HOST}%{REQUEST_URI}_\.js\.gz [L,QSA,T=text/javascript,E=no-gzip:1]

  # NORMAL - Cached css & js files
  RewriteCond %{DOCUMENT_ROOT}/cache/perm/%{HTTP_HOST}%{REQUEST_URI}_\.css -s
  RewriteRule .* cache/perm/%{HTTP_HOST}%{REQUEST_URI}_\.css [L,QSA,T=text/css]
  RewriteCond %{DOCUMENT_ROOT}/cache/perm/%{HTTP_HOST}%{REQUEST_URI}_\.js -s
  RewriteRule .* cache/perm/%{HTTP_HOST}%{REQUEST_URI}_\.js [L,QSA,T=text/javascript]

  # Caching for anonymous users
  # Skip boost IF not get request OR uri has wrong dir OR cookie is set OR request came from this server OR https request
  RewriteCond %{REQUEST_METHOD} !^(GET|HEAD)$ [OR]
  RewriteCond %{REQUEST_URI} (^/(admin|cache|misc|modules|sites|system|openid|themes|node/add|comment/reply))|(/(edit|user|user/(login|password|register))$) [OR]
  RewriteCond %{HTTPS} on [OR]
  RewriteCond %{HTTP_COOKIE} DRUPAL_UID
  RewriteRule .* - [S=5]  # Added 2 to this value to accommodate added rules for Apache 2.4

  # GZIP
  RewriteCond %{HTTP_COOKIE} !(boost-gzip)
  RewriteCond %{HTTP:Accept-encoding} !gzip
  RewriteRule .* - [S=2]  # Added 1 to this value to accommodate added rule for Apache 2.4
  RewriteCond %{DOCUMENT_ROOT}/cache/normal/%{HTTP_HOST}%{REQUEST_URI}_%{QUERY_STRING}\.html\.gz -s
  RewriteRule .* cache/normal/%{HTTP_HOST}%{REQUEST_URI}_%{QUERY_STRING}\.html\.gz [L,T=text/html,E=no-gzip:1]
  # Special handling for front page for Apache 2.4
  RewriteCond %{REQUEST_URI} ^/index\.php$
  RewriteCond %{DOCUMENT_ROOT}/cache/normal/%{HTTP_HOST}/\_%{QUERY_STRING}\.html\.gz -s
  RewriteRule .* cache/normal/%{HTTP_HOST}/\_%{QUERY_STRING}\.html\.gz [L,T=text/html,E=no-gzip:1]

  # NORMAL
  RewriteCond %{DOCUMENT_ROOT}/cache/normal/%{HTTP_HOST}%{REQUEST_URI}_%{QUERY_STRING}\.html -s
  RewriteRule .* cache/normal/%{HTTP_HOST}%{REQUEST_URI}_%{QUERY_STRING}\.html [L,T=text/html]
  # Special handling for front page for Apache 2.4
  RewriteCond %{REQUEST_URI} ^/index\.php$
  RewriteCond %{DOCUMENT_ROOT}/cache/normal/%{HTTP_HOST}/\_%{QUERY_STRING}\.html -s
  RewriteRule .* cache/normal/%{HTTP_HOST}/\_%{QUERY_STRING}\.html [L,T=text/html]

  ### BOOST END ###

  # Rewrite URLs of the form 'x' to the form 'index.php?q=x'.
  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteCond %{REQUEST_FILENAME} !-d
  RewriteCond %{REQUEST_URI} !=/favicon.ico
  RewriteRule ^(.*)$ index.php/?q=$1 [L,QSA]  # Added '/' before '?' for Apache 2.4

As before, the changes are tagged with a comment including "Apache 2.4". Philip's note in #27 about modifying the added rewrite rules for use in a subdirectory still applies.

While I don't have the resources to check the .htaccess workarounds provided above against non-Apache servers, I've verified that both the D6 and D7 versions function normally on Apache versions 1.3.41 and 2.2.25 in addition to the problematic 2.4.6. Perhaps they could be provided in a Boost update and optionally disabled via a checkbox for non-Apache systems.

While no module patch has been provided, I'm going to set the issue status to "Needs review" for now in the hope of attracting additional testers for the proposed workaround.

Came across this issue and found a solution in #25. This was the only way I was able to get my front page to serve its cached version. All other pages were serving correctly and I could see that the front page was being cached, but until using jerry's code I could not get the front page to be served. I had tried every combination of Server's URL/Document Root in the UI with no success. Based on #33, #35, and my testing I'm going to mark this as RTBC. Hope that's not premature. Thanks jerry!

I confirm : solution #25. works ; I hope for an official patch

P.S. thanks Jerry

Probably I found another bug related to boost and apache 2.4 : after applying of patch #25, l If I make a search from the cached homepage as anonymous user ( I mean from a search block in the home ) and if the searched term is not in the database I don't see anything: there is no redirect to /search/node page with the message "Your search yielded no results ecc. ".. nothing happens and I remain in the home page.

If I make the same exact thing from a different page ( a cached page as anonymous user ) everything works, I'm redirected to search/node; the problem on the home page is not present if i try to search after doing login.

I've tried on two or three sites, no one of them is in a subfolder.

I've tried on two or tree sites, no one of them is in a subfolder.

I can confirm this behavior, at least on D7. The cache files for searches from the search block on the home page are not generated, and the site appears to redirect to the home page immediately. I don't have an appropriate site for testing this on D6 immediately available.

I don't have an appropriate site for testing this on D6 immediately available.

I can now confirm that D6 exhibits the same behavior.

Correction:

and if the searched term is not in the database I don't see anything

the search won't work even if the entry is in the database, instead of the list of the found terms i continue to see the homepage

I'm going to downgrade my VPS from Apache 2.4.x to Apache 2.2.x.
If someone is going to release a patch I'll test it on a local virtual machine, so I hope I can be helpful in some way.

Anyway thanks for your help :-)

Am I correct in assuming that if caching for .xml and .json is also enabled, that additional rules need to be added to #25 as they appear in the .htaccess Generation page for the #GZIP and #NORMAL sections? And does “[S=5]” need to be set to “S=7” and “[S=2]” need to be set to “[S=4]” accordingly? And if only one of the two were activated, S should be set equal to 6 and 3, respectively?

Just observe the comments:

RewriteRule .* - [S=5]  # Added 2 to this value to accommodate added rules for Apache 2.4
RewriteRule .* - [S=2]  # Added 1 to this value to accommodate added rule for Apache 2.4

You need only add the indicated deltas to whatever skip values were auto-generated by Boost. Those values already reflect the XML/JSON choices. If you change your caching choices in Boost, it may be simplest to start over and re-apply the edits in this issue to the resulting set of rules.

Okay, for awhile I couldn’t get the caching to work at all until I implemented the change I described in my #49. However, doing so with the .xml and .json caching activated had a strange side-effect: Boost was now caching for logged-in users as well, including Admins, and redirecting all Admin URLs to the home page, completely locking out all Admin and other logged-in users from their special functions! (But hey, at least it did so very quickly!)

So, I commented out the lines involving the XML and JSON caching and set the two [S=#]s back to 2 less than I’d had them, namely to what is shown in @Philip_Clarke’s #25, then disabled those functions in the Boost configuration. Now everything is working properly.

I may try to re-enable XML caching alone, and JSON alone, and see which is causing this problem (I strongly suspect JSON). It may need another Issue (if so, I’ll create one and link this one to it as Related and/or Parent Issue), but since it can be invoked by people trying to implement the fix given here, I think it important to mention in it in this thread as well. I would like to cache at least XML for feeds.

Ah, figured out my #51. Thanks to @jerry’s #50, I figured out what “[S=#]” means: Skip Rules. So, setting those correctly solved that problem, and I have my XML and JSON caching enabled! Thanks! No new Issue will be forthcoming.

#25 and #36 also works for me but while there is not a patch this issue can't have a different status that "needs work"

Also... i'm not sure if i'm the only one but, this patch makes fail the Search block in the homepage

You are not the only one, the search block in home page won't work.

Very good news :-) , thanks.

Disable search.php in Boost' settings

Philip, can you be more specific about this? I have a number of D6 and D7 sites that will have their Apache version upgraded from 2.2.x to 2.4.x this week, ready or not, and some of them have the search form enabled on the front page. I'd love a workaround for that short of disabling caching for the entire front page, if it exists.

On my D7 test site, this didn't affect the problem that occurs when the front page search block is used. The symptom is as described above: upon submission of the search block form, the front page simply refreshes, the URL doesn't change, and of course no results are displayed.

If I visit /search instead of using the block, all appears to work normally without disabling search caching.

I fear that I am going nowhere, fast.

The form POST action is just "/", and no search code is being invoked at all when executed from the front page. After clearing the Boost cache, logging out and attempting to perform a search from the front page block, the cache contains only .htaccess and _.html. No search folder is created. It's as though the check for GET|HEAD is being ignored, though I don't how that could happen.

FWIW, the original problem was reported with Apache 2.4.6; I'm now seeing it with 2.4.9 as well.

Submitting the search block form from the front page with the redirect patches previously posted applied results in a re-load of the front page from the Boost cache, which can be verified by the presence of the Boost footer comment. I haven't tested the behavior without the patches applied.

What I am finding now is that Apache 2.4.7 serves everything correctly in a sub folder, and that with the original rules everything works except for the front page. So the tests I need done are to find the original rules and confirm that boost will serve everything except for the front page.

For what it's worth, I have representative D6/D7 systems running Boost 6.x-1.21/7.x-1.0-beta2 on Ubuntu 12.04.2 LTS. Using the original Apache 2.4.6 available at site installation, the front page problems described above were present. (I can't comment on subfolder issues.) The host skipped 2.4.7 and recently installed 2.4.9 on these servers. I've reverted to the .htaccess rules generated by Boost, discarding the workarounds posted above, and found that the front page and search block features again work normally on 2.4.9.

Using the new -dev release seems to work fine until I try to log in. Immediately on entering user name and password credentials (whether correct or incorrect), it does “Internal Server Error 500.” Fortunately, I have a logged in session still active in another browser session from before I activated Boost, and it still works.

Commenting out all Boost lines in .htaccess restores the ability to log in again. Uncommenting them, with or without also uncommenting RewriteBase / above the ### BOOST START ###, causes it to fail again.

Please help!

Everything else (that I’ve tried so far) appears to work fine. Front page gets cached and shows Boost comment at the bottom. Not tried Search yet.

For now, I could tell the client to let me know when they need to log in, and I can briefly comment out those lines long enough for them to log in, then uncomment them again. Once they’re in, it’s fine. It’s only the actual login process that errors out.

This could even have a side benefit of enhancing security, since basically no hacker could log in either except during the few seconds that I have Boost disabled. ;-) (Just trying to see the bright side here…)

Just tried Search: it, too, 500s, so the workaround isn’t all that acceptable either.

Apache version 2.4.9

Debian 6.0.8 running Apache 2.4.9 and PHP 5.4.27. Site works fine (albeit slowly) when Boost commented out.

Oops! Not Debian. Used wrong SSH session to another server. The one in question doesn't appear to have a version or release file that I have even Read permissions on in /etc/ (there is a “/etc/.etc.version” but I have no permissions on it, not even read), so I have no idea how to tell what distro it is. It is Apache 2.4.9 and PHP 5.4.27, though.

Hi Friend,

I faced the same problem for this but now its working.Actually problem was that for front page it was not reading the _.html cached page and searched for the index.php_.html so made some changes in code and its working now if you say i will give you the solution.

Thanks
Pritika

Hi Philip,

As this is a major issue and for many users it would take a long time to figure out that there is a conflict with apache version and boost. It would be great if you can add a line mentioning the issue with Apache 2.4 and refer to this page for more details or to suggest dev version etc,.
Currently, it is mentioned that Apache is fully supported. Irrespective of being a regular user of boost I din't doubt something like this until after couple of days.

Even a minor note on the project page would be greatly helpful.

Regards
Chakrapani

I have D6 running on a newly upgraded Ubuntu 14.04 with Apache 2.4. I've managed to get Boost working using the changes to .htaccess described in comment #25. I'm still having no luck with the front page search form however. I installed the latest dev version of Boost which doesn't improve the situation. Were can I find info on the two lines in .htaccess to comment out, as described in #82 ? My current .htaccess rules are pasted below. Do I still need to comment out these lines, with the settings that I have. Also, have others got the front page search form working on D6, or is it simply broken?

Thanks

### BOOST START ###
# See https://www.drupal.org/node/2078595 #25 for special settings for Apache 2.4

# Caching for anonymous users
# Skip boost IF not get request OR uri has wrong dir OR cookie is set OR request came from this server OR https request
RewriteCond %{REQUEST_METHOD} !^(GET|HEAD)$ [OR]
RewriteCond %{REQUEST_URI} (^/(admin|cache|misc|modules|sites|system|openid|themes|node/add|comment/reply))|(/(edit|user|user/(login|password|register))$) [OR]
RewriteCond %{HTTPS} on [OR]
RewriteCond %{HTTP_COOKIE} DRUPAL_UID
#RewriteRule .* - [S=1]
RewriteRule .* - [S=2] # Added 2 to this value to accommodate added rules for Apache 2.4

# NORMAL
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]
#Special handling for front page for Apache 2.4
RewriteCond %{REQUEST_URI} ^/index\.php$
RewriteCond %{DOCUMENT_ROOT}/cache/normal/%{SERVER_NAME}/\_%{QUERY_STRING}\.html -s
RewriteRule .* cache/normal/%{SERVER_NAME}/\_%{QUERY_STRING}\.html [L,T=text/html]
#End Apache 2.4 rules

### BOOST END ###

While the front page is being cached wonderfully with the .htaccess rules in #25, the search block form, when filled out and submitted, simply refreshes the front page, instead of redirecting to the search results page. This only happens on the front page of the website.

Oops, spoke too soon... The dev version's .htaccess rules worked flawlessly on Apache 2.4.7.

https://bz.apache.org/bugzilla/show_bug.cgi?id=56434

this has been resolved on apache >= 2.4.9

We've just upgraded our servers to 2.4.12 and the bug is gone.

Apache 2.4.7
Boost 7.x-1.x-dev

Frontpage cache file (_.html) got refreshed every time when I access the front page.

my htaccess:

#
# Apache/PHP/Drupal settings:
#

# Protect files and directories from prying eyes.
<FilesMatch "\.(engine|inc|info|install|make|module|profile|test|po|sh|.*sql|theme|tpl(\.php)?|xtmpl)(~|\.sw[op]|\.bak|\.orig|\.save)?$|^(\..*|Entries.*|Repository|Root|Tag|Template)$|^#.*#$|\.php(~|\.sw[op]|\.bak|\.orig\.save)$">
  Order allow,deny
</FilesMatch>

# Don't show directory listings for URLs which map to a directory.
Options -Indexes

# Follow symbolic links in this directory.
Options +FollowSymLinks

# Make Drupal handle any 404 errors.
ErrorDocument 404 /index.php

# Set the default handler.
DirectoryIndex index.php index.html index.htm

# Override PHP settings that cannot be changed at runtime. See
# sites/default/default.settings.php and drupal_environment_initialize() in
# includes/bootstrap.inc for settings that can be changed at runtime.

# PHP 5, Apache 1 and 2.
<IfModule mod_php5.c>
  php_flag magic_quotes_gpc                 off
  php_flag magic_quotes_sybase              off
  php_flag register_globals                 off
  php_flag session.auto_start               off
  php_value mbstring.http_input             pass
  php_value mbstring.http_output            pass
  php_flag mbstring.encoding_translation    off
</IfModule>

# Requires mod_expires to be enabled.
<IfModule mod_expires.c>
  # Enable expirations.
  ExpiresActive On

  # Cache all files for 2 weeks after access (A).
  ExpiresDefault A1209600

  <FilesMatch \.php$>
    # Do not allow PHP scripts to be cached unless they explicitly send cache
    # headers themselves. Otherwise all scripts would have to overwrite the
    # headers set by mod_expires if they want another caching behavior. This may
    # fail if an error occurs early in the bootstrap process, and it may cause
    # problems if a non-Drupal PHP file is installed in a subdirectory.
    ExpiresActive Off
  </FilesMatch>
</IfModule>

# Various rewrite rules.
<IfModule mod_rewrite.c>
  RewriteEngine on

  # Set "protossl" to "s" if we were accessed via https://.  This is used later
  # if you enable "www." stripping or enforcement, in order to ensure that
  # you don't bounce between http and https.
  RewriteRule ^ - [E=protossl]
  RewriteCond %{HTTPS} on
  RewriteRule ^ - [E=protossl:s]

  # Make sure Authorization HTTP header is available to PHP
  # even when running as CGI or FastCGI.
  RewriteRule ^ - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

  # Block access to "hidden" directories whose names begin with a period. This
  # includes directories used by version control systems such as Subversion or
  # Git to store control files. Files whose names begin with a period, as well
  # as the control files used by CVS, are protected by the FilesMatch directive
  # above.
  #
  # NOTE: This only works when mod_rewrite is loaded. Without mod_rewrite, it is
  # not possible to block access to entire directories from .htaccess, because
  # <DirectoryMatch> is not allowed here.
  #
  # If you do not have mod_rewrite installed, you should remove these
  # directories from your webroot or otherwise protect them from being
  # downloaded.
  RewriteRule "(^|/)\." - [F]

  # If your site can be accessed both with and without the 'www.' prefix, you
  # can use one of the following settings to redirect users to your preferred
  # URL, either WITH or WITHOUT the 'www.' prefix. Choose ONLY one option:
  #
  # 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} .
  # RewriteCond %{HTTP_HOST} !^www\. [NC]
  # RewriteRule ^ http%{ENV:protossl}://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%{ENV:protossl}://%1%{REQUEST_URI} [L,R=301]

  # Modify the RewriteBase if you are using Drupal in a subdirectory or in a
  # VirtualDocumentRoot and the rewrite rules are not working properly.
  # For example if your site is at http://example.com/drupal uncomment and
  # modify the following line:
  # RewriteBase /drupal
  #
  # If your site is running in a VirtualDocumentRoot at http://example.com/,
  # uncomment the following line:
  # RewriteBase /

  
  ### BOOST START ###

  # Allow for alt paths to be set via htaccess rules; allows for cached variants (future mobile support)
  RewriteRule .* - [E=boostpath:normal]

  # Apache 2.4 bug workaround
  # Enables Search from home page https://drupal.org/node/2078595#comment-8724321
  RewriteCond %{REQUEST_METHOD} ^(POST)$
  RewriteCond %{REQUEST_URI} /
  RewriteRule .* / [S=3]

  # Caching for anonymous users
  # Skip boost IF not get request OR uri has wrong dir OR cookie is set OR request came from this server OR https request
  RewriteCond %{REQUEST_METHOD} !^(GET|HEAD)$ [OR]
  RewriteCond %{REQUEST_URI} (^/(admin|cache|misc|modules|sites|system|openid|themes|node/add|comment/reply))|(/(edit|user|user/(login|password|register))$) [OR]
  RewriteCond %{HTTPS} on [OR]
  RewriteCond %{HTTP_COOKIE} DRUPAL_UID [OR]
  RewriteCond %{ENV:REDIRECT_STATUS} 200
  RewriteRule .* - [S=2]

  # Apache 2.4 bug workaround
  # Enables caching of index/ home page
  RewriteCond %{REQUEST_URI} ^/index\.php$
  RewriteCond %{DOCUMENT_ROOT}/cache/%{ENV:boostpath}/%{HTTP_HOST}/\_%{QUERY_STRING}\.html -s
  RewriteRule .* cache/%{ENV:boostpath}/%{HTTP_HOST}/\_%{QUERY_STRING}\.html [L,T=text/html]

  # NORMAL
  RewriteCond %{DOCUMENT_ROOT}/cache/%{ENV:boostpath}/%{HTTP_HOST}%{REQUEST_URI}_%{QUERY_STRING}\.html -s
  RewriteRule .* cache/%{ENV:boostpath}/%{HTTP_HOST}%{REQUEST_URI}_%{QUERY_STRING}\.html [L,T=text/html]

  ### BOOST END ###


  # Pass all requests not referring directly to files in the filesystem to
  # index.php. Clean URLs are handled in drupal_environment_initialize().
  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteCond %{REQUEST_FILENAME} !-d
  RewriteCond %{REQUEST_URI} !=/favicon.ico
  RewriteRule ^ index.php [L]

  # Rules to correctly serve gzip compressed CSS and JS files.
  # Requires both mod_rewrite and mod_headers to be enabled.
  <IfModule mod_headers.c>
    # Serve gzip compressed CSS files if they exist and the client accepts gzip.
    RewriteCond %{HTTP:Accept-encoding} gzip
    RewriteCond %{REQUEST_FILENAME}\.gz -s
    RewriteRule ^(.*)\.css $1\.css\.gz [QSA]

    # Serve gzip compressed JS files if they exist and the client accepts gzip.
    RewriteCond %{HTTP:Accept-encoding} gzip
    RewriteCond %{REQUEST_FILENAME}\.gz -s
    RewriteRule ^(.*)\.js $1\.js\.gz [QSA]

    # Serve correct content types, and prevent mod_deflate double gzip.
    RewriteRule \.css\.gz$ - [T=text/css,E=no-gzip:1]
    RewriteRule \.js\.gz$ - [T=text/javascript,E=no-gzip:1]

    <FilesMatch "(\.js\.gz|\.css\.gz)$">
      # Serve correct encoding type.
      Header set Content-Encoding gzip
      # Force proxies to cache gzipped & non-gzipped css/js files separately.
      Header append Vary Accept-Encoding
    </FilesMatch>
  </IfModule>
</IfModule>

If I enable the first Apache 2.4 bug workaround and do not comment out the skip line I end up with a 500 error. Any ideas?

### BOOST START ###

# Allow for alt paths to be set via htaccess rules; allows for cached variants (future mobile support)
RewriteRule .* - [E=boostpath:normal]

# Apache 2.4 bug workaround
# Enables Search from home page https://drupal.org/node/2078595#comment-8724321
RewriteCond %{REQUEST_METHOD} ^(POST)$
RewriteCond %{REQUEST_URI} /
# RewriteRule .* / [S=3]

# Caching for anonymous users
# Skip boost IF not get request OR uri has wrong dir OR cookie is set OR request came from this server OR https request
RewriteCond %{REQUEST_METHOD} !^(GET|HEAD)$ [OR]
RewriteCond %{REQUEST_URI} (^/(admin|cache|misc|modules|sites|system|openid|themes|node/add|comment/reply))|(/(edit|user|user/(login|password|register))$) [OR]
RewriteCond %{HTTPS} on [OR]
RewriteCond %{HTTP_COOKIE} DRUPAL_UID [OR]
RewriteCond %{ENV:REDIRECT_STATUS} 200
RewriteRule .* - [S=3]

# Apache 2.4 bug workaround
# Enables caching of index/ home page
RewriteCond %{REQUEST_URI} ^/index\.php$
RewriteCond %{DOCUMENT_ROOT}/cache/%{ENV:boostpath}/%{HTTP_HOST}/\_%{QUERY_STRING}\.html -s
RewriteRule .* cache/%{ENV:boostpath}/%{HTTP_HOST}/\_%{QUERY_STRING}\.html [L,T=text/html]

# NORMAL
RewriteCond %{DOCUMENT_ROOT}/cache/%{ENV:boostpath}/%{HTTP_HOST}%{REQUEST_URI}_%{QUERY_STRING}\.html -s
RewriteRule .* cache/%{ENV:boostpath}/%{HTTP_HOST}%{REQUEST_URI}_%{QUERY_STRING}\.html [L,T=text/html]
RewriteCond %{DOCUMENT_ROOT}/cache/%{ENV:boostpath}/%{HTTP_HOST}%{REQUEST_URI}_%{QUERY_STRING}\.xml -s
RewriteRule .* cache/%{ENV:boostpath}/%{HTTP_HOST}%{REQUEST_URI}_%{QUERY_STRING}\.xml [L,T=application/xml]

### BOOST END ###

# Pass all requests not referring directly to files in the filesystem to
# index.php. Clean URLs are handled in drupal_environment_initialize().
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !=/favicon.ico
RewriteRule ^ index.php [L]

Does anyone have any kind of feedback as to what might be going on? Following is what I get if I put apache into debug mode:

[Mon Jan 11 17:01:22.745593 2016] [core:error] [pid 8979] [client XXX.XXX.XXX.XXX:24577] AH00124: Request exceeded the limit of 10 internal redirects due to probable configuration error. Use 'LimitInternalRecursion' to increase the limit if necessary. Use 'LogLevel debug' to get a backtrace., referer: http://www.mysite.org/user/login?current=index
[Mon Jan 11 17:01:22.747332 2016] [core:debug] [pid 8979] core.c(3613): [client XXX.XXX.XXX.XXX:24577] AH00121: r->uri = /, referer: http://www.mysite.org/user/login?current=index
[Mon Jan 11 17:01:22.747359 2016] [core:debug] [pid 8979] core.c(3620): [client XXX.XXX.XXX.XXX:24577] AH00122: redirected from r->uri = /, referer: http://www.mysite.org/user/login?current=index
[Mon Jan 11 17:01:22.747376 2016] [core:debug] [pid 8979] core.c(3620): [client XXX.XXX.XXX.XXX:24577] AH00122: redirected from r->uri = /, referer: http://www.mysite.org/user/login?current=index
[Mon Jan 11 17:01:22.747394 2016] [core:debug] [pid 8979] core.c(3620): [client XXX.XXX.XXX.XXX:24577] AH00122: redirected from r->uri = /, referer: http://www.mysite.org/user/login?current=index
[Mon Jan 11 17:01:22.747412 2016] [core:debug] [pid 8979] core.c(3620): [client XXX.XXX.XXX.XXX:24577] AH00122: redirected from r->uri = /, referer: http://www.mysite.org/user/login?current=index
[Mon Jan 11 17:01:22.747429 2016] [core:debug] [pid 8979] core.c(3620): [client XXX.XXX.XXX.XXX:24577] AH00122: redirected from r->uri = /, referer: http://www.mysite.org/user/login?current=index
[Mon Jan 11 17:01:22.747448 2016] [core:debug] [pid 8979] core.c(3620): [client XXX.XXX.XXX.XXX:24577] AH00122: redirected from r->uri = /, referer: http://www.mysite.org/user/login?current=index
[Mon Jan 11 17:01:22.747465 2016] [core:debug] [pid 8979] core.c(3620): [client XXX.XXX.XXX.XXX:24577] AH00122: redirected from r->uri = /, referer: http://www.mysite.org/user/login?current=index
[Mon Jan 11 17:01:22.747482 2016] [core:debug] [pid 8979] core.c(3620): [client XXX.XXX.XXX.XXX:24577] AH00122: redirected from r->uri = /, referer: http://www.mysite.org/user/login?current=index
[Mon Jan 11 17:01:22.747498 2016] [core:debug] [pid 8979] core.c(3620): [client XXX.XXX.XXX.XXX:24577] AH00122: redirected from r->uri = /, referer: http://www.mysite.org/user/login?current=index
[Mon Jan 11 17:01:22.747516 2016] [core:debug] [pid 8979] core.c(3620): [client XXX.XXX.XXX.XXX:24577] AH00122: redirected from r->uri = /user/login, referer: http://www.mysite.org/user/login?current=index
[Mon Jan 11 17:01:22.747574 2016] [core:error] [pid 8979] [client XXX.XXX.XXX.XXX:24577] AH00124: Request exceeded the limit of 10 internal redirects due to probable configuration error. Use 'LimitInternalRecursion' to increase the limit if necessary. Use 'LogLevel debug' to get a backtrace., referer: http://www.mysite.org/user/login?current=index

I just for grins and giggles changed the first rewrite rule to RewriteRule .* - [S=3] instead of RewriteRule .* / [S=3] and things seem to be working. Comments?

re #91 I'm getting that 500 error as well.

Seems to be only related to the Apache 2.4 workarounds. And I was able to reproduce it submitting any form in the admin page.

I'm re-opening this issue to address that.

It probably needs this looooong exclusion condition as well on that workaround:

 RewriteCond %{REQUEST_URI} (^/(admin|cache|misc|modules|sites|system|openid|themes|node/add|comment/reply))|(/(edit|user|user/(login|password|register))$) [OR]

I have that long line in their already it is only if I change the / to a - in the first workaround that I do not seem to have the 500 error. What is the / supposed to do?

Thanks

I am running Apache/2.4.6 (CentOS) and if I uncomment the search box fix

  RewriteCond %{REQUEST_METHOD} ^(POST)$
  RewriteCond %{REQUEST_URI} /
  RewriteRule .* / [S=3]

I get 500 error when I try to log in to the site. Without uncommenting it, the search box does not work for anon users.

The server is also behind a proxy...

Eric

I am not sure if I have the same problem: As soon as I change the php version to 5.4 (tested with 5.4.9 and 5.4.16) the cached filed get not generated any more. Php-versions 5.2 and 5.3 are working like a charm.

Running Apache 2.2.2
Php 5.5

The same situation like in #97
Search page didn't tested - i don't using it.

Old htaccess rules - worked fine...

  ### BOOST START ###

  # Allow for alt paths to be set via htaccess rules; allows for cached variants (future mobile support)
  RewriteRule .* - [E=boostpath:normal]

  # Caching for anonymous users
  # Skip boost IF not get request OR uri has wrong dir OR cookie is set OR request came from this server OR https request
  RewriteCond %{REQUEST_METHOD} !^(GET|HEAD)$ [OR]
  RewriteCond %{REQUEST_URI} (^/(admin|cache|misc|modules|sites|system|openid|themes|node/add|comment/reply))|(/(edit|user|user/(login|password|register))$) [OR]
  RewriteCond %{HTTPS} on [OR]
  RewriteCond %{HTTP_COOKIE} DRUPAL_UID [OR]
  RewriteCond %{ENV:REDIRECT_STATUS} 200
  RewriteRule .* - [S=3]

  # GZIP
  RewriteCond %{HTTP:Accept-encoding} !gzip
  RewriteRule .* - [S=1]
  RewriteCond %{DOCUMENT_ROOT}/cache/%{ENV:boostpath}/%{HTTP_HOST}%{REQUEST_URI}_%{QUERY_STRING}\.html\.gz -s
  RewriteRule .* cache/%{ENV:boostpath}/%{HTTP_HOST}%{REQUEST_URI}_%{QUERY_STRING}\.html\.gz [L,T=text/html,E=no-gzip:1]

  # NORMAL
  RewriteCond %{DOCUMENT_ROOT}/cache/%{ENV:boostpath}/%{HTTP_HOST}%{REQUEST_URI}_%{QUERY_STRING}\.html -s
  RewriteRule .* cache/%{ENV:boostpath}/%{HTTP_HOST}%{REQUEST_URI}_%{QUERY_STRING}\.html [L,T=text/html]

  ### BOOST END ###

And also - there was # GZIP part.
In new code no # GZIP code.
It is need to?

This will sever front page search problem:

function themename_form_alter(array &$form, array &$form_state = array(), $form_id = NULL) {

switch ($form_id) {
case 'search_block_form':
if (drupal_is_front_page()) $form['#action'] = '/search';
break;
}

}

As per #101, that didn't work for me but changing the form action like so worked:

function themename_form_alter(array &$form, array &$form_state = array(), $form_id = NULL) {
	switch ($form_id) {
	case 'search_block_form':
	if (drupal_is_front_page()) $form['#action'] = '/search/node';
		break;
	}
}

Another option that should work is using jQuery to adjust the form action:

$('body.front form#search-block-form').attr('action', 'search/node');

I just had another look into this problem, when I did the update von 1.2.

My advice: Take the code generated by the boost-Module (1.2), keep the two Apache 2.4 bug workarounds commented out and change the line

RewriteRule .* - [S=2]

into

RewriteRule .* - [S=1]

With this change, all involved problems ( the problem of this issue + https://www.drupal.org/node/2421879 + https://www.drupal.org/node/2719795) are gone!

Related issue: https://www.drupal.org/node/2814113

is this going to make it into a release? As pointed out, boost is broken OOTB because of that small directive

#103 solution worked for me.

Hola

Tengo el problema de cache. A mi me genera el fichero de cache con cada acceso lo cual quiere decir que no tira de cache D7

Uso php 7.2
Apache 2.4.29
D7.60

He probado cambiando algunas de las lineas del fichero .htaccess y aplicando alguna solución de las que vi en la comunidad pero el resultado es él mismo.

A alguien más le pasa esto ?

Hi,

html files are saved to server, and they are updated after every refresh.
Still I think the server is not serving any files, I cant see the boost header or the code in the source.

I have apache 2.4.33

What could be the solution, or is there any. Only when apache bug lines are commented out, no 500 server error comes.