Thu, 02 Feb 2006
Moving to Apache 2
In the last few days we have finally moved IS MU to the Apache 2.0. Well, in the meantime the 2.2 branch has been released, but we will try 2.0 first. I wrote about some problems with mod_perl2, today I will add few more:
- The SERVER_PORT environment variable is set in a different way under Apache 2.0 - with 1.3 it reflects the request's URL, with 2.0 it reflects the actual port Apache is listening on (which may be different if there is a port redirection or NAT, as in our case).
- IPC::Open3 does not work under mod_perl2. This is a known issue, with recommendation to use IPC::Run or IPC::Run3 instead. As I do not need to simultaneously write to and read from the other process, I have simply rewritten it to use the temporary files instead of IPC::Open3.
Possibly the most tricky part is that the local redirection works differently. In Apache 1.3, when the application sent out the Location: header, which was a relative or server-relative URI, the HTTP server itself issued a sub-request to that different URI, without involving the client.
In Apache 2.0, the server happily forwards the Location: header to the client, with a default status code of 200, and with an empty page body (which can confuse MSIE somewhat, I have to say :-). The internal redirects have to be called via the Apache2::SubRequest->internal_redirect() method. However, this method does not accept a fully relative URI (such as running the same script with different arguments using the myscript.pl?arg=val location). The server-relative URI has to be used instead.
Moreover, this does not work for setting a different QUERY_STRING: when the original request had a non-empty query string, it remains to be set even in the subrequest. However, for original request without the query string, the new arguments are set correctly in the subrequest. I suspect this to be a bug in CGI.pm, because I have checked that the environment variables are set correctly even in the subrequest. I have temporarily solved this by using the external redirects (with 302 status and the Location: header).
In spite of the above problems, we are now running Apache 2.0 on our production servers, and we can move on to upgrade our infrastructure to use UTF-8 even at the HTTP server layer (our DB is already in UTF-8, as I wrote before).