Main | February 2008 »

6 posts from January 2008


Production use for the Include Directive

At work we've finally gotten to the point architecturally where we are no longer implementing a brand new web site (with new server infrastructure) for every application so now it is time to start investigating ways to better manage httpd.conf. When you are part of a group of three or more administrators, each new application that comes along could have it's own Apache settings, mod_proxy settings, jkmounts, rewrites, etc., and they could be scattered all over the place within the httpd.conf. Managing the configuration becomes fairly difficult, especially if each new release contains minor changes to the main configuration file.

Simply create a new .conf file for the application and then use the apache Include directive to refer to the additional configuration file.

This idea is new to me--but it is not a new idea. I saw it after recently compiling a copy of apache on my own machine. It involves setting up separate configuration files per site, application, virtual server and just including them within the main apache configuration file.

Let's say you want to add php5 support into your apache server instance. Create a new configuration file that contains the following base configuration directives:

 LoadModule php5_module modules/
# This section adds filetype support for php files
<IfModule mod_php5.c>
AddType application/x-httpd-php .php .phtml
AddType application/x-httpd-php-source .phps

# This enables index.php as a default directory document
<IfModule mod_dir.c>
DirectoryIndex index.html index.php
Then, in your httpd.conf file, add the following at the bottom:
# Add PHP5 support into httpd.conf
Include httpd-php5.conf

It's pretty useful when you get 5 or 6 (or more!) different applications that might have their own mod_rewrite statements, aliases, jk mounts, mod_proxy balancer statements or virtual hosts. apachectl -configtest will still run through each configuration file in order to check the syntax of all directives and you will wind up saving time hunting for application-specific configuration data--assuming, of course, that you used descriptive names for these additional files.


Second Post

Well, that first post didn't turn out as nicely formatted as I had hoped. This second one will be done using an eval of MarsEdit, which I will happily buy if everything works out well with it.

I'm new to blogging. I have lots of experience with web servers, application servers, etc., which I've gained over the past 10+ years but most of my experience has been on the infrastructure and operations side. In order to become more familiar with the development side, I've created this site. Hopefully my html, css, scripting, and related skills will increase over the course of time as well but for the time-being, I need something easy. I'm not ready yet to start delving into customized stylesheets.

Using the online editor, I wound up spending a little bit of time trying to figure out how to stop getting the editor to reformat a link as an actual Hyperlink and the only way I was able to get it done was by dropping the "<" at the beginning of the "a href". If I'm going to type a bit of markup in a post like I plan on doing with this site, for example, I'd like to display the actual markup. The online editor kept wanting to display mark-up as a hyperlink instead. So, this first test will involve me re-inputting the mark-up from the previous post in order to see how it looks once it is posted to the live site.
<a href=""> Product Manuals </a>

Finally, the last line of the first post was not intended to be wrtten as "Ditto for those base href's that some folks are so fond of. Avoid absolute URLs and base href's if at all possible." What I really wanted to write was:

Ditto for the <base href> tag!

Previewing in marsedit with the Textile Preview Text Filter looks promising. I hope it looks this good live!

Gripe: Absolute URL versus Relative URL

Ah FrontPage. You made it so easy to create web sites that there are many, **many** web site developers out there who do not know the difference between an absolute URL and a relative URL. I'm not talking about those cases when you need to link somewhere offsite--I'm talking about links to content that reside on your own site. Yes, this first post is a gripe. You would be surprised with how many times I come across this when we're going through a site. I once spent a couple of hours on the phone going over the differences between absolute URLs, relative URLs, and, of course, the server relative URL with a group of developers and I think by the end of the conversation, they were just saying "ok" to get me off the phone. What's wrong with using an absolute URL within your own site to link to your own content? Consider the following HTML for a fictional company's product manuals.

Absolute URL Example

a href=""> Product Manuals

Relative URL Example

a href="manual/index.html"> Product Manuals

Although both work and will result in loading the same page, the first will make troubleshooting problems with the web site a little bit tougher.

Consider the following example: runs across a pair of web servers, and A browser making a request for the homepage hits the load-balancer and the load-balancer sends that request off to one of the two real web servers. Now let's say that some of our customers are reporting an "intermittent" problem with one of the two web servers getting the manual. We operations-types fire up a browser and go to, (bypassing the load-balancer), and then click the link for the manuals. The trouble hits when we click that link. Due to there being an absolute URL, our browser gets sent back to the address instead of going to the real server. If we experience a 404-Not Found error, we still don't really know which server is generating the error.

I understand that this example may be over-simplistic because since we assumed these were static pages, then we could just go to and see if we get an error and repeat the step for serverB. This becomes more annoying when there are dynamically-generated URLs and you have to go to the homepage, login, etc. Obviously, the scope of this article is geared towards web sites developed and running within the enterprise. Sites that are load-balanced because they have to be up. Sites that cost the company serious money when they are down.

Ditto for those base href's that some folks are so fond of. Avoid absolute URLs and base href's if at all possible.