« June 2008 | Main | August 2008 »

22 posts from July 2008


The X-Forwarded-For Header

Most mainstream proxy servers support what is known as the X-Forwarded-For header, which is a custom header that gets inserted into the HTTP request by the proxy so that the Client IP Address can be read by the target web/app server. The Wikipedia article describes it much better than I could--this article focuses on how to set things up on your BigIP or your apache server so that this useful IP address can get passed along to your upstream server.

For all intents and purpsoses, the BigIP is a reverse proxy--a high end, load-balancing, application delivery proxy, but nevertheless, it is a proxy. By default, requests sent to it are natted to a load-balanced node. By default, the web server does not see the IP address of the end-user--it sees the IP address of the bigip. This makes setting up things like IP Address Restrictions or Geo-Location services difficult because all your users will look like they are coming from the same place inside your network.
mod_proxy load-balancing requests to an upstream application server puts the apache httpd server in reverse proxy mode for that particular web app as well--so for those web applications that need to see the client ip address for reasons similar to the above, then they are out of luck as well.

Enabling the X-Forwarded-For Header in the BigIP

The X-Forwarded-For header is enabled and disabled from within the HTTP profile in the 9.x version of the BigIP software. If you are using the base http profile in your VIPs (or if you are using an HTTP profile that uses the base http profile as a "parent profile") and you have not modified the base http profile, then this option is disabled by default. Enabling is simply a matter of selecting "Enabled" from the dropdown labeled "XForwarded-for" and you are all set!

Ok....you aren't really all set. All this does is configure VIPs that utilize this particular profile to insert the X-Forwarded-For header in requests that will be routed to a particular web server. If the web server doesn't know what to do with this header, it will cheerfully ignore it. F5 also developed an isapi plug-in for IIS that will write the IP address of the client into the web server's log in place of the BigIPs address. For apache web servers, you will need to modify the LogFormat directive so that you drop the %h (client ip) field and replace it with the %{X-Forwarded-For}i field.

Enabling the X-Forwarded-For Header in mod_proxy

Now that you are passing the client IP address to your web server, what if you want to pass the client IP address along to your application servers as well? Well, if you're using mod_proxy_http (or mod_proxy_balancer with workers that are using mod_proxy_http), then you don't really need to do anything. The documentation on the apache site implies that mod_proxy automatically forwards three headers (X-Forwarded-For, X-Forwarded-Host, and X-Forwarded-Server).


Apache Combined and CombinedIO Logs

The combined log file format in apache combines user agent data, referral data, and regular access into a single file. "Combined Log Format" for the history buffs out there looking to impress the ladies is actually known as the NCSA Extended/Combined Log Format.

The apache combinedio log file format is an add-on in the form of a module named mod_logio. It provides two additional fields you can add to your combined logs--bytes in and bytes out per request.

Logs are defined using the LogFormat directive. A definition of the combined log looks something like this:
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\"" combined

Load up the mod_logio.so module, you can add the two additional fields to this format like so:
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\" %I %O" combined
Note the addition of the %I and %O near the end of the line. Nothing else needs to change.

If you allow (in test) access to content that should otherwise be SSL encrypted over an unencrypted channel, then using the CombinedIO format will give you an accurate comparison of the impact that encryption provides on the size of your content. What it should also provide is an interesting before and after comparison of the impact of compression on content so you can impress your bosses with all that bandwidth savings everyone keeps telling us that compression provides.

Back in the day, we oldy timey webmasters would run these logs through something like HitList or Webalizer or NetGenesis and provide all these prettied up reports for the business users and dream about insidious schemes to charge back our group's costs to the business based upon number of hits. But, alas, Google Analytics, CoreMetrics, and the rest of the hosted solutions killed that dream.


What a difference a ping makes!

Long time readers of this blog may remember (and based upon google analytics stats, there were no long-time readers for the first half of this year), a post regarding blog editors from me. I was using Zoundry Raven for a while because I was too cheap to invest in BlogJet but about three or four weeks ago, I switched over to a combination of ScribeFire, MarsEdit (for offline writing of much longer posts), and the regular blogger rich-text editor, (which this post is being written in).

I started this blog back in January but outside of writing up some articles and posting them whenever, I did not really invest too much more personal time in this site. When I went on vacation this past June, I decided to start taking it a little bit more seriously and start experimenting with the site a little bit. It was at this time that I switched back to ScribeFire and began making use of ScribeFire's built-in facility for pinging popular blog directories when a post is published. My goodness, what a difference. My monthly visits alone are the following:

January 2008 38 Visits
February 2008 42 Visits
March 2008 58 Visits
April 2008 36 Visits
May 2008 18 Visits
June 2008 11 Visits
July 2008 (as of 07/23) 122 Visits

Still, not many comments, which is too bad because it really is the only way I currently have to determine whether a particular article is correct and/or useful. Perhaps the next area of focus should be the inclusion of some kind of rating mechanism for articles on this site.