Hello,

I keep getting 500 Internal Server Errors on all form submits after upgrade to Boost 7.x-1.2. I am running Apache/2.4.10 (Debian). I have also uncommented the lines for the Apache 2.4 bug workaround. Every time I am trying to login a Server error 500 shows up. Same issue with "Options +SymLinksIfOwnerMatch" enabled. It's happening on multiple sites. It’s definitely related to Boost. How can I debug this further?

.htaccess generation from 7.x-1.2:

  ### 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=5]

  # 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=4]

  # 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=text/xml]
  RewriteCond %{DOCUMENT_ROOT}/cache/%{ENV:boostpath}/%{HTTP_HOST}%{REQUEST_URI}_%{QUERY_STRING}\.json -s
  RewriteRule .* cache/%{ENV:boostpath}/%{HTTP_HOST}%{REQUEST_URI}_%{QUERY_STRING}\.json [L,T=text/javascript]

  ### BOOST END ###

When I use the following boost .htaccess generation from previous boost versions, everything is back to normal.:

  ### 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=7]

  # GZIP
  RewriteCond %{HTTP:Accept-encoding} !gzip
  RewriteRule .* - [S=3]
  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]
  RewriteCond %{DOCUMENT_ROOT}/cache/%{ENV:boostpath}/%{HTTP_HOST}%{REQUEST_URI}_%{QUERY_STRING}\.xml\.gz -s
  RewriteRule .* cache/%{ENV:boostpath}/%{HTTP_HOST}%{REQUEST_URI}_%{QUERY_STRING}\.xml\.gz [L,T=text/xml,E=no-gzip:1]
  RewriteCond %{DOCUMENT_ROOT}/cache/%{ENV:boostpath}/%{HTTP_HOST}%{REQUEST_URI}_%{QUERY_STRING}\.json\.gz -s
  RewriteRule .* cache/%{ENV:boostpath}/%{HTTP_HOST}%{REQUEST_URI}_%{QUERY_STRING}\.json\.gz [L,T=text/javascript,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]
  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=text/xml]
  RewriteCond %{DOCUMENT_ROOT}/cache/%{ENV:boostpath}/%{HTTP_HOST}%{REQUEST_URI}_%{QUERY_STRING}\.json -s
  RewriteRule .* cache/%{ENV:boostpath}/%{HTTP_HOST}%{REQUEST_URI}_%{QUERY_STRING}\.json [L,T=text/javascript]

  ### BOOST END ###

Comments

howdytom created an issue. See original summary.

philsward’s picture

Can you post the full .htaccess generation including the 2.4 workarounds? It "might" have something to do with the [S=?] part of the generation.

Starting with 1.1 (and the apache 2.4 workarounds) the generation does some goofy things.

howdytom’s picture

Issue summary: View changes

yeah, I have updated my previous post.

howdytom’s picture

Issue summary: View changes
philsward’s picture

Looking at the diff between the two, I don't see why the 1.2 generation shouldn't be working. The only thing I can come up with is that the apache 2.4 workaround lines are causing issues.

If you want to dive in and figure out "if" either one is causing the problem, comment each one individually but make sure to change the [S=?] line for the anonymous user caching. If you aren't familiar, that line basically says "if the above rules match, skip the next [n] rules".

Commenting the first 2.4 workaround shouldn't make any difference to the [S=?] line in: # Caching for anonymous users

However, if you comment the 2nd 2.4 workaround, you will need to change:
# Caching for anonymous users
RewriteRule .* - [S=4] -> RewriteRule .* - [S=3]

(commenting out the 2nd work around means there are only 3 rules below the anonymous caching that need skipped instead of 4 because you commented out one rule)

howdytom’s picture

Thank you philsward. When I comment out the first 2.4 workaround the Error 500 is gone. What exactly does it do? Is it required?

#  # 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=5]
philsward’s picture

@howdytom it isn't "necessary" unless you plan to use the core search block on the home page. For some reason, when the home page is cached by boost, without that rule set, the search doesn't do anything. Just sits there when you click the button.

That rule set is supposed to workaround that problem.

If you aren't using the core search functionality on the site, you can leave it commented.

Some suggestions are to make sure "RewriteBase" is uncommented in the .htaccess. Another thought is to make sure the base_url and cookie domain are both uncommented and setup in the settings.php file. Honestly dunno if those will help, but worth a try.

howdytom’s picture

Thank you for your explanation. Actually I am also using the core search block. Commenting out base_url, cookie domain or RewriteBase didn’t work for me. I’ve switched back to the »old« htaccess generation which is working fine.

Moreover I’ve also noticed a incompatibility issue with Adv CSS/JS Agg module: HTTP Request error message on Drupal Status Page.

AdvAgg will issue a request for a file that does not exist inside of the AdvAgg directory. If AdvAgg sends a 404, everything is ok; if something else sends a 404 then that means that AdvAgg will not be able to generate an aggregate if it is missing as something else is handling the 404 before AdvAgg has a chance to do it. If you are reading this, it means that something else is handling the 404 before AdvAgg can. Raw request info:
stdClass::__set_state(array(
   'request' => 'GET /sites/default/files/advagg_js/js__1479380128.js HTTP/1.0
Connection: close
philsward’s picture

Odd the workaround is causing more problems than it's helping... Definitely something going on there that is beyond my knowledge to fix :-/

If it's working by leaving it commented, then that's one work around. My other thought would be to not cache the home page, but that would be pointless since the 2.4 workaround in question is designed specifically FOR the home page.

I guess if you figure anything else out, post back.