Apache 2.2 has some great hidden treasures in it that a lot of folks are simply unaware of.
Apache 2.2 has been out for a while, and just recently, 2.2.13 was released, featuring the usual slate of enhancements and bug fixes. Happily, the migration to 2.2 seems to be proceeding apace faster than the migration from 1.3 to 2.0, and most people, finally, seem to have jettisoned Apache 1.3.
However, it also seems that a lot of folks are completely unaware of some of the cool new things available in 2.2. Sites are so used to Apache just working; most don’t think about the new features that are going into the Web server all the time.
Here, let’s look at some of the more exciting innovations found in 2.2 and perhaps peek at one or two of the more esoteric ones. You may be surprised and amazed by what’s been lying under your nose all this time.
I realized long ago that leaving the best to last merely ensures that most people won’t make it that far. So, let’s start with the most compelling feature. If you merely read this first page, you’ll still be ahead of the other system administrators in your office.
Since the beginning of time (the beginning of the web, anyways) SSL suffered from a fundamental shortcoming. Simply stated, you had to have one IP address for every new SSL host that you wanted to run. (The exact origin of this limitation isn’t terribly important right here. You can find a number of articles on the subject elsewhere.) But now that we’ve finally arrived in the 21st Century, you can finally run multiple SSL virtual hosts on the same IP address. You can do this with something called Server Name Indication (SNI).
The deal with SSL is that you don’t know what name is being requested until after the certificate — possibly the wrong one — has already been exchanged. With SNI, this is addressed by sending the server name as part of the initial negotiation, so that you get the certificate that goes with the right name.
Apache 2.2.12 contains SNI, and you can now serve multiple SSL hosts off of one IP address. More good news is that every modern browser supports this feature and has for some time, just waiting for more sites to implement it on the server side. The bad news is that the documentation is somewhat behind the implementation, but hopefully that will get resolved real soon now.
At the moment, however, the best documentation for this functionality is in the docs wiki, at http://wiki.apache.org/httpd/NameBasedSSLVHostsWithSNI. The docs wiki is sort of a staging ground for the Apache documentation, so that stuff eventually makes it into the official docs.
A frequently asked question on the various Apache support forums is how to modify the content within a page as it is being served out to the client. For example, if you’re proxying to a back-end server and that server has URLs embedded in the pages that point to that back-end server, the end-user on the Internet, being unable to reach that back-end server directly, simply experiences a bunch of broken links. So what’s to be done? In the past there wasn’t much that could be done, short of using a third-party module called mod_proxy_html, which was written specifically for this situation. You can read more about it, as well as more about the situation it attempts to resolve, at http://apache.webthing.com/mod_proxy_html/.
But there is a larger class of problems at hand. What if you just want to modify something in content that’s being served to the end users? Perhaps you’re running a third-party application and don’t have access to the source to customize it, but you want to make some modifications to the output that it produces.
Another module, also available at webthing.com, is mod_line_edit (http://apache.webthing.com/mod_line_edit/) allows you make arbitrary modifications, using sed-like syntax, to the outgoing HTTP response body.
Apache 2.2 introduced mod_substitute, which includes some of the functionality of both of the latter modules and allows you to modify the response that is being sent to the web client, using regular expressions. While this doesn’t do anything that mod_line_edit, or Basant Kukreja’s mod_sed don’t do, it has the advantage of being part of the Apache 2.2 distribution, and so it’s one less step to acquire it.
To use mod_substitute, you must know enough about regular expressions to express your desired change. For example, if you are proxying a back-end server images.local and want to replace that hostname in URLs with its external hostname, you would do the following:
AddOutputFilterByType SUBSTITUTE text/html
In this case, the
i on the end indicates that the substitution should happen in a case-insensitive fashion. The
AddOutputFilterByType directive specifies what kind of files the substitution should affect. You don’t want to do substitutions on images or PDF files, for example, as it will corrupt them and result in garbage.
Place these directives in a
<Location> block where you want it to be in effect, or in a .htaccess file, if you don’t have access to the main server configuration file.
This may not seem like a big deal, but folks have been asking for it for a long time. Apache 2.2 adds the
graceful-stop option, to stop the server … um … gracefully.
Usually, when you stop, or restart Apache, it kills all the existing client connections as part of the process. This results in angry end-users, and your phone rings, and your boss yells at you. Yelling is generally to be avoided.
So, a long, long time ago, the
graceful-restart option was added, which allows you to restart the server, but without abruptly terminating in-process client connections.
$ httpd -k graceful-restart
But there are times when you need to shut down a server entirely, and in that case, too, the clients are abruptly dropped. For example, you may want to take a server out of a load-balanced configuration, but you don’t want existing client sessions to be terminated. So what do you do?
Well, with Apache 2.2, a new option stops the server but allows ongoing connections — say, if someone is executing a long-running script or downloading a large file — to complete before the child processes are killed.
$ httpd -k graceful-stop
This has the direct result of your phone ringing less when you’re doing server maintenance. Highly recommended.
A lot has been written about mod_proxy_balancer, yet every time I mention it, someone is surprised that this is an included feature of the Apache product. So, here again, mod_proxy_balancer.
Apache 2.2 comes with a front-end proxy that load balances between an arbitrary number of back-end servers. It also maintains sticky sessions; that is, once a client is routed to a particular server, you can force that client to always go back to that server, so that their sessions are not interrupted. It does traffic-based load balancing. It does hot spares: a server can be automatically rolled into the rotation if one of the other ones dies. It has a Web-based management console where you can remove servers from the rotation or modify a server’s priority in the rotation.
So, it’s really a full-featured load balancing proxy. And it’s free, and included in your Apache 2.2 server.
To get started with mod_proxy_balancer, define your pool, or “cluster” of hosts to be balanced:
Then, tell your server to proxy requests through to those servers:
ProxyPass /test balancer://mycluster/
If that seems deceptively easy … well, it actually is that easy, but you can also configure a raft of other options on top of that, including those mentioned above.
As with the other features I’ve mentioned, I’m not going to reproduce the documentation here. Instead, take a look at the examples at http://httpd.apache.org/docs/2.2/mod/mod_proxy_balancer.html