As a system admin or developer, you’ll be routinely faced with the need to create a reverse proxy through a web server. Initially the task of setting up a target location for your redirected connection can seem like an extremely simple and effortless process. However, later, you’ll realize that your biggest challenge emerges when the […]
As a system admin or developer, you’ll be routinely faced with the need to create a reverse proxy through a web server. Initially the task of setting up a target location for your redirected connection can seem like an extremely simple and effortless process. However, later, you’ll realize that your biggest challenge emerges when the authenticated layout within the server destroys the relative paths when you are modifying the structure of pre-set URLs. This will ruin your entire presentation as everything from videos, images, css style-sheets and any other resources won’t be accurately displayed. So, here’s a step-by-step guide that allows you to create a reverse proxy using IIS.
So, a URL rewrite is basically an IIS extension that you’ll have to download from:
http://www.iis.net/downloads/microsoft/url-rewrite.
This enables you to rewrite any URL while it is being executed either outbound or inbound, hence the name. This makes it the ideal too to create a reverse proxy, if your only purpose is to forward the request made.
In order to rewrite the code, you need to download and install software that allows you to reconfigure the contents of a response, when it gets volleyed back to client server. URL Rewrite 2.0 is the perfect tool for this as it allows you rewrite links without necessitating touching the coding in the actual application.
Here’s a list of software that you’re going to need:
If you’re wondering where you can these modules from, Microsoft’s Web Platform Installer (WPI) would be the safest and quickest way to download and install them. The best part about using WPI is that it handles all dependencies, if any.
Now you’re going to have to setup inbound and outbound rules, but you’re going to have to capture all requests onto a root folder, in this case business1/*, so if you’re using a Default Web Site, anything that gets sent to http://localhost/business1/* will be linked through this rule, which will then rewrite it as www.business1.com, in compliance with HTTP vs HTTPS traffic rules.
The Code should look something like this:
<rule name="Route the requests for Business1" stopProcessing="true">
<match url="^business1/(.*)" />
<conditions>
<add input="{CACHE_URL}" pattern="^(https?)://" />
</conditions>
<action type="Rewrite" url="{C:1}://www.business1.com/{R:1}" />
<serverVariables>
<set name="HTTP_ACCEPT_ENCODING" value="" />
</serverVariables>
</rule>Now, let us set up a proper diversion, which involves the following steps:
Once you’ve set up the application request routing code, you’re going to have to rewrite the inbound rules that will decipher incoming client request, using a public address. This will facilitate the transition to an internal server, as opposed to an exposed server, while also retaining parts of the request that do not need to be translated.
The figure below explains how this can be done:
You might also want to keep the following key points in mind.
Once you’ve completed the inbound rule rewrite, you’re going to have to work on the outbound rules that will effectively modify the response sent from the client server. This is required if you want the links within to point to your reverse proxy instead of the actual server.
You might wonder whether you have to do this because it involves absolute links like (change http://soft1/icon.png to http://www.proxy.com/domain/soft1/icon.png), or even relative links like (change /icon.png to /domain/soft1/icon.png). Well, if you don’t do this:
So technically, you will rewrite at least some of the links, unless of course, you have a single page application!
Some important tips while writing rules:
Author: Rahul Sharma
