Here’s the situation.. we have a legacy Classic ASP site that we are moving to more scalable and stable environment… Since we want to have multiple web servers handling the load during peak hours (it runs just fine on one right now) and be able to perform new releases along with testing during off peak times while the website continues to run on one server. This also means that we can easily throw more webservers into the mix should that be necessary later.

The easy (and open-source and free) solution is to use Apache as a reverse proxy.  This also allows for some other neat tricks (mod_security, mod_deflate) without having to deal with Windows and IIS configuration.. or make any code changes for that matter.

The problem comes in with how Classic ASP deals with cookies. Deep in the bowels of ASP, Microsoft was benevolent enough to add in HTML encoding of your cookie’s name and value. This actually isn’t a horrible thing as it prevents some poorly written code from creating an exploitable bug (HTTP Header injection), but its a bit overzealous and there’s no way to alter its behavior. You’re simply stuck with it.

Of course, if you’re happily writing ASP code, it gets encoded and decoded for you so you never even know its going on.

ASP Code to set a cookie:

Response.Cookies(”SERVERID”) = “balancer.www2″

ASP Code to display that cookie:

Response.Write “Cookie: ” & Request.Cookies(”SERVERID”)

Outputs:

SERVERID: balancer.www2

The problem lies in what is actually being sent by IIS:

Set-Cookie: SERVERID=balancer%2Ewww2; path=/

%2E is simply an HTML Encoded period. I’ve never known a period within a string to cause a security issue… but it gets encoded anyway. Apache’s mod_proxy_balancer looks at that cookie and expects to find a period within it, using the part after the period to determine which server that person should get sent back to.

I spent a large part of the day thinking the issue was an Apache configuration issue, as even with debug logging on, it wasn’t outputing anything. Once I looked through the code for mod_proxy_balancer, i saw that it ignores the cookie unless there’s a period in the string, and clearly there wasn’t one in my string.

After spending about 5 minutes trying to find a way to disable or change that behavior within ASP (there isn’t any as far as I can tell), I quickly found a solution within Apache!

Since Apache 2.2.4, the mod_headers module provides a method to edit a header using a regular expression. I was already using mod_headers to pass along some values through Apache (like the external IP address, or if the request was over HTTPS), so simply adding one line to the Apache configuration file fixed the issue:

Header edit Set-Cookie balancer%2Ewww balancer.www

Now, apache watches the response headers for when we are setting a cookie,  and if it contains “balancer%2Ewww” it gets rewritten as “balancer.www” and sure enough both Apache and IIS are perfectly happy with the cookie and everything is working well.

If I didn’t have access to the source code, it would have taken me weeks of trial and error to determine what the issue was or it would have been given up on for simply being incompatible. If apache wasn’t as flexible as it is, i would have been stuck writing a patch to mod_proxy_balancer and recompiling my own apache rather then relying on the distro’s packages for updates.

This is exactly where the closed source commercial software (Microsoft) and, to a much lessor-extent, the walled-garden open-source approach (like Django) run into issues. As long as you are only using that vendor’s software in the way that the vendor envisioned you would be using it, you’re just fine. Its also why standards are a good thing.

Yet another example of why Mark Ramm was right when he wrote and talked about WSGI being the right way to write tools that properly interact with one another. I’m really convinced now that the TurboGears/Pylons approach is the proper way to build web applications.