Virtual Hosts (Apache) with mod_rewrite issues

Question

I am trying to fix this whole day without success, so I hope someone might be able to help me. I have an app at http://localhost/ , and it uses Pylons for the app I am hosting. In addition to that, I need to host a PHP/MySQL site, so I had to use Apache too.

My current setup is that I use haproxy with this config for the Apache backend:

backend apache

mode http
timeout connect 4000
timeout server 30000
timeout queue 60000
balance roundrobin

server app02-8002 localhost:8002 maxconn 1000

This is triggered by this:

acl image url_sub images
use_backend apache if image

So, when I open my IP/images, it will trigger that and open Apache then, with port 8002.

For Apache, I created virtual hosts, and this is the "image" one:

<VirtualHost *:8002>
 ServerAdmin my@email.com
 ServerName image
 ServerAlias image
 DocumentRoot /srv/www/image/public_html/
 ErrorLog /srv/www/image/logs/error.log
 CustomLog /srv/www/image/logs/access.log combined
</VirtualHost>

So, that all works nicely, when I type IP/images it open the /srv/www/image/public_html. But then the issues come. As I am using the image uploading script, it involves a lot of rewriting, so I had to enable that mod. This is the .htaccess which is located in the public_html/images folder (I somehow had to make this subfolder too, to "match" the URL with the actual location in the public_html. SetEnv PHP_VER 5_3

RewriteEngine On
# You must define your installation directory and uncomment the line :
RewriteBase /images/

RewriteRule ^([a-zA-Z]+)\.(jpg|gif|png|wbmp)$ controller/Resizer.php?m=original&a=$1&e=$2 [L]
RewriteRule ^(icon|small|medium|square)\/([a-zA-Z]+)\.(jpg|gif|png|wbmp)$ controller/Resizer.php?m=$1&a=$2&e=$3 [L]

RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule (.*) application.php?request=$1 [L,QSA]

So, basically, this is somethow not working. I suppose there is a conflict between this virtual host, subdirectory, rewriting or something, but I can't seem to isolate it.

It is a bit confusing that when I open the IP/images/xxxx.jpg it opens the image, which is located in the public_html/images/upload/original folder, so the rewrite is working. The the other rules seem not to be working. All of the thumbnails and smaller versions are not rendering properly (with the icon, small, medium, square), so that makes the site quite unsusable.

Here is the link of the development server: http://localhost/images/

Thanks in advance for your time and help!

Answer 1

The first thing you should do is determine whether mod_rewrite is in fact part of the problem by accessing one of the failing URLs directly via its rewritten form and verifying that you get the expected result.

Indeed, the problem might simply be that the PHP script for the smaller resolutions "doesn't work" while it does for the original size ones. The first of the following URLs nicely served me an image; the second one is supposed to give me a smaller version of the same image, but served me an HTTP 500:

http://106.186.21.176/images/controller/Resizer.php?m=original&a=q&e=png  
http://106.186.21.176/images/controller/Resizer.php?m=small&a=q&e=png

I got the same result (HTTP 500) for any of the smaller-size format names mentioned in your post, which matches your problem description.

Once you've verified that the script works as expected, it's likely that the problem is with mod_rewrite. If so, enable rewrite logging: use the RewriteLog directive to activate it, and RewriteLogLevel to control its verbosity. Especially at the higher log levels, it can give you very detailed information about exactly what it's doing. This should make the problem readily apparent from the logs.

Also, if possible, try to avoid configuring mod_rewrite rules in .htaccess files -- move them into your main server config file instead. The reason is explained on Apache mod_rewrite Technical Details , section "API phases":

Unbelievably mod_rewrite provides URL manipulations in per-directory context, ie, within .htaccess files, although these are reached a very long time after the URLs have been translated to filenames. It has to be this way because .htaccess files live in the filesystem, so processing has already reached this stage. In other words: According to the API phases at this time it is too late for any URL manipulations. To overcome this chicken and egg problem mod_rewrite uses a trick: When you manipulate a URL/filename in per-directory context mod_rewrite first rewrites the filename back to its corresponding URL (which is usually impossible, but see the RewriteBase directive below for the trick to achieve this) and then initiates a new internal sub-request with the new URL. This restarts processing of the API phases.

Again mod_rewrite tries hard to make this complicated step totally transparent to the user, but you should remember here: While URL manipulations in per-server context are really fast and efficient, per-directory rewrites are slow and inefficient due to this chicken and egg problem. But on the other hand this is the only way mod_rewrite can provide (locally restricted) URL manipulations to the average user.

In general, not using .htaccess at all has the added advantage that you can tell Apache to not even bother and disable the functionality all together, which save Apache from having to scan each directory level it serves from for the .htaccess files.