Tricky Apache modules

Every day we work on improving out techniques to cover more and more systems. To implement more and more methods. To test and choose the best techniques to speed up website around us.

Apache modules

When we speak about PHP proxy to server your pages fast a reasonable question arises - why should we relate to Apache? Is it a PHP solution or something else? The answer is very simple: we try to reduce server side load with every possibility. If Apache can gzip content - let's do this. If Apache can cache - let's also do it (Apache can be used as a backend for a complex web system, so this doesn't change a lot even if there is nginx / lighttpd / squid frontend).

Of course we can't write to Apache configuration file. It's very dangerous. And it's restricted with all hosting providers. But Apache has very useful feature in this area - .htaccess file. It provides full access to directives which have Location level (it's enough in almost all cases).

Well... What's wrong with .htaccess?

It's OK with it. We also have a Wiki page with recommended rules for .htaccess (or Apache configuration file).

Troubles begin when we are working not with mod_php environments but with CGI ones.

Apache modules detection

So to use all Web Optimizer features properly we need to know for sure what modules exist, and skip processing of a part of logic via PHP to save server resources, i.e. gzip via Apache or PHP, cache via Apache or PHP, or anything similar. To detect all allowed Apache modules we use apache_get_modules function. It can give us all the information about server if there is mod_php. Otherwise we need to use another approach. What is it?

First of all we need to check for .htaccess possibility (just download restricted file, if we can do this - .htaccess doesn't work). Then we can module by module write required rules (one test rule just to check module existence) to temporary .htaccess and get any file (via curl) from the folder with this .htaccess. If we can do this - all is OK, Apache module is enabled. If we can't (i.e. 500 error occures) - we disable such module in configuration and going to provide the same functionality via PHP.

That's all?

Yes, the whole process looks like this:

• Check for .htaccess possibility (it also can be restricted in Apache configuration).
• Check for Apache modules (via API or raw approach with curl).
• Write all possible rules to .htaccess.
• Provide all missed functionality via PHP.