SSL HTTP 403.4 Redirects and Different App-Pools


IIS is great, but sometimes it can bite you in the ass very hard. A while ago, we discovered that there was a certain configuration which had everyone’s head scratching for a while.

Let us first talk about the configuration that we had on board.

Solution Deployment

We have several deployable web projects as part of our entire solution. Therefore, under the default web site, we have each project being deployed as a virtual directory.

SSL Configuration

Basically, the setup in bullet form was (as an example from SSL Shopper):

  • Configure the HTTPS binding with the SSL certificate
  • Set the web site to require SSL.
  • And to tackle the HTTP 403.4 error that the previous step introduced, write a small little ‘handler’ to redirect the people who landed on the HTTP side to the HTTPS site. This was configured on the root web site, where all our projects were deployed to.

That configuration was done a long time ago, and somewhat forgotten how or what was done.

Different Application Pools

Lately, we have been in a pursuit of performance and better isolation between the different projects in our solution. When we set out to do this, we settled on that we were going to isolate each virtual directory with their own application pool, and in addition to the very busy virtual directories, we were going to make them into web gardens as well.

Then things broke. Well, only on the SSL redirect part.

Diagnostics

After fiddling around, we eventually found a clue in our IIS logs: a HTTP 500.18 was being returned where we were expecting a HTTP 403.4 at least. Upon further investigation, we found that the ‘handler’ script, that I mentioned above, was trying to execute the script via a loopback (remember the Server.Tranfer() method in classic ASP?).

Because that file was logically on another application domain, it was failing to execute.

Solution

Once we figured out what was happening, we knew that we could tackle this in many ways. Here are some solutions that were on the cards:

  • Using URL Rewrite (example here).
  • Respond with a hard redirect (HTTP 301) to redirect to the appropriate home screen.
  • Add the custom ‘handler’ script for each virtual directory so that it executes within the same application domain.
blog comments powered by Disqus