D-talk - Apache

Multiple PHP versions on one webserver

nospam@example.com (Mark van der Velden) — Tue, 03 Nov 2009 08:39:00 +0100

Introduction

This is a blog about running two PHP versions on one webserver and using multiple php.ini files, this combination can be a tricky one to tackle. But luckily one we can tackle quite easily as long as one of the PHP versions is >= 5.2.7. For this example I'll be using Apache, but the webserver flavor doesn't really matter. The most important part is the "PHP_INI_SCAN_DIR" environment variable.

The why

There could be a number of reasons to want what I'm about to talk about. In my case I have a project where I have a legacy code-base, running on a specific PHP version, and a new code-base which will be run on 5.3. Because the new code-base will be a ongoing progress of replacing the old, it first has to run side by side with the legacy code-base. So I wanted my development image to run two PHP versions.

The old code-base used php.ini settings such as a include-path, error reporting, etc. Which will be different from the new code-bas, and those can no-longer be set with the 'php_value' feature of Apaches since the PHP version we'll be using for that runs as (f)CGI rather then as module.

Continue reading "Multiple PHP versions on one webserver"

Apache's fail with 'encoded slashes'

nospam@example.com (Mark van der Velden) — Thu, 25 Jun 2009 14:58:45 +0200

Honestly it took me a while to debug a vague bug I had, at first I ignored it and used different path values, figuring it was a bad rewrite rule. I'm using a project and I'm developing on both Apache and IIS, with the one inconsistency that I always got a 404 when the path contained a encoded /, namely "%2F". So basically, a URL like this: http://domain.com/show/article/104671-Situation%20details%20n%2Fa (Title being: "Situation details n/a") is giving a 404. The error log was helpful, because it said:

[..] [info] [client 127.0.0.1] found %2f (encoded '/') in URI (decoded='//'), returning 404

Luckily, fixing this ~~bug~~ feature is easy. Add the following to your httpd.conf (vhost or server directive) and voila:

AllowEncodedSlashes On

Arguably you could be saying that %2F's simply shouldn't be in the path, but rather in the POST body or as GET parameter. However in a world where everything has to be SEO and url's have to be pretty, isn't this silly default behavior ? Especially since the RFC's also clearly state that an encoded forward slash (%2F) should not be treated as a regular '/'. To quote RFC 2616

Characters other than those in the "reserved" and "unsafe" sets (see RFC 2396 [42]) are equivalent to their ""%" HEX HEX" encoding.

and RFC 2396

2.2. Reserved Characters

   Many URI include components consisting of or delimited by, certain
   special characters.  These characters are called "reserved", since
   their usage within the URI component is limited to their reserved
   purpose.  If the data for a URI component would conflict with the
   reserved purpose, then the conflicting data must be escaped before
   forming the URI.

      reserved    = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" |
                    "$" | ","

RewriteRule [L]

nospam@example.com (Mark van der Velden) — Sun, 21 Oct 2007 15:14:40 +0200

Mod_rewrite and the [L] modifier, you'd think the documentation says it all. But once again we are fooled!

I don't read a whole lot of blogs and if I read them I scout for the most interesting entries, some dating way back and some are current. Sometimes I put them on my own blog to have a 'repository' of interesting articles, which I'm going to do with this one also. I can't explain it any better then Etienne himself does.

This time it's about Apache and the mod_rewrite L modifier. An entry by Etienne Kneuss about last not being last at all.
http://www.colder.ch/news/01-26-2007/24/truth-about-the-last-mod_.html