the default rewrite rules for boost look something like this:
RewriteCond %{DOCUMENT_ROOT}/cache/%{SERVER_NAME}/0%{REQUEST_URI} -d
RewriteCond %{DOCUMENT_ROOT}/cache/%{SERVER_NAME}/0%{REQUEST_URI}/index.html -f
RewriteRule ^(.*)$ cache/%{SERVER_NAME}/0/$1/index.html [L]

however, the boosted files are being written to a directory based on the URL (and hence based on the Host header).

In case when the URL have a different host header then the default SERVER_NAME, this makes boost write the files but apache never reads them.

For example: my host's server_name is 'example.com' but the URL it is being accessed at is 'beta.example.com'.

This can be fixed by changing the rewrite rules to use %{HTTP_HOST} instead of %{SERVER_NAME}
or by changing the way boost write it's files. I think the former is better.

sorry for not submitting a real patch, it has been a long day :-)

CommentFileSizeAuthor
#4 boost-DRUPAL-5.http_host.patch1.74 KBsun

Comments

Arto’s picture

Arto commented
Title: rewrite rules using wrong SERVER_NAME » SERVER_NAME vs HTTP_HOST in rewrite rules

As I recall this has got changed around, back and forth, a few times already. Things are never as simple as they appear, and there are trade-offs to using either one. Especially when it comes to multisite functionality, it's highly configuration and context-dependent which one is the one an admin will want.

If you want to pursue this, please have a look at related older closed issues. I'm not sure I would want to change this again without somebody first doing a comprehensive trade-off analysis.

Arto’s picture

Arto commented
Status: Active » Postponed (maintainer needs more info)
sun’s picture

sun
Primary language German
Location Karlsruhe
commented
Status: Postponed (maintainer needs more info) » Active

Is there a reason why we cannot check for both?

  RewriteCond %{DOCUMENT_ROOT}/cache/%{HTTP_HOST}/0/index.html -f
  RewriteRule ^(.*)$ cache/%{HTTP_HOST}/0/index.html [L]
...
  RewriteCond %{DOCUMENT_ROOT}/cache/%{HTTP_HOST}/0%{REQUEST_URI} -d
  RewriteCond %{DOCUMENT_ROOT}/cache/%{HTTP_HOST}/0%{REQUEST_URI}/index.html -f
  RewriteRule ^(.*)$ cache/%{HTTP_HOST}/0/$1/index.html [L]
...
  RewriteCond %{DOCUMENT_ROOT}/cache/%{HTTP_HOST}/0%{REQUEST_URI}.html -f
  RewriteRule ^(.*)$ cache/%{HTTP_HOST}/0/$1.html [L]
...
  RewriteCond %{DOCUMENT_ROOT}/cache/%{SERVER_NAME}/0/index.html -f
  RewriteRule ^(.*)$ cache/%{SERVER_NAME}/0/index.html [L]
...
  RewriteCond %{DOCUMENT_ROOT}/cache/%{SERVER_NAME}/0%{REQUEST_URI} -d
  RewriteCond %{DOCUMENT_ROOT}/cache/%{SERVER_NAME}/0%{REQUEST_URI}/index.html -f
  RewriteRule ^(.*)$ cache/%{SERVER_NAME}/0/$1/index.html [L]
...
  RewriteCond %{DOCUMENT_ROOT}/cache/%{SERVER_NAME}/0%{REQUEST_URI}.html -f
  RewriteRule ^(.*)$ cache/%{SERVER_NAME}/0/$1.html [L]
sun’s picture

sun
Primary language German
Location Karlsruhe
commented
Status: Active » Needs review
StatusFileSize
new boost-DRUPAL-5.http_host.patch1.74 KB

The same as patch. Maybe this could even optimized to use chained rewrite rules.

nirl’s picture

nirl commented

Hey Arto and Sun.

I found the reason you switched from HTTP_HOST to SERVER_NAME. It's here: http://drupal.org/node/101427

I am working with HTTP_HOST in production with two sites running (using host-header-based virtual hosting and drupal multi-size config (sites/site1.com/... sites/site2.com)

I think using both SERVER_NAME and HTTP_HOST is redundant, slower and will not produce the expected results since the issue the guy at issue 101427 had is (i am guessing) that he had two sites on different ports. The only way to handle such cases is to write to a directory with the port part (example.com:80 example.com:81 - use both the port part of the parse_url) and have the rewrite rules take into account both HTTP_HOST and HTTP_PORT. It's a bit of work and requires alot of testing but i am sure you can handle this.

IMHO this issue should be documented in the example .htaccess and HTTP_HOST should be used by default as this the the correct setting for most production systems (there are very few port based virtual hosts out there).

thanks for the feedback and sorry for the late reply.

mikeytown2’s picture

mikeytown2 commented
Status: Needs review » Closed (fixed)

Closing all 5.x issues; will only reevaluate if someone steps up #454652: Looking for a co-maintainer - 5.x

Reason is 6.x has 10x as many users as 5.x; also last 5.x dev was over a year ago. The 5.x issue queue needs to go.