IIS URL Rewrite supports server variables for pretty much every part
of the URL and http header. However, there is one commonly used server variable that isn’t readily available. That’s the protocol—HTTP or HTTPS. You can easily check if a page request uses HTTP or HTTPS, but that only works in the conditions part
of the
rule. There isn’t a variable available to dynamically set the protocol in the action part
of the
rule. What I wish is that there would be a variable like {HTTP_PROTOCOL} which would have a value
of ‘HTTP’ or ‘HTTPS’. There is a server variable called {HTTPS}, but the values
of ‘on’ and ‘off’ aren’t practical in the action. You can also use {SERVER_PORT} or {SERVER_PORT_SECURE}, but again, they aren’t useful in the action. Let me illustrate. The following
rule will redirect traffic for http(s)://localtest.me/ to http://www.localtest.me/. <rule name="Redirect to www">
<match url="(.*)" />
<conditions>
<add input="{HTTP_HOST}" pattern="^localtest\.me$" />
</conditions>
<action type="Redirect" url="http://www.localtest.me/{R:1}" />
</rule>
The problem is that it forces the request to HTTP even if the original request was for HTTPS.
Interestingly enough, I planned to blog about this topic this week when I noticed in my twitter feed yesterday that Jeff Graves, a former colleague
of mine, just wrote an excellent blog post about this very topic. He beat me to the punch by just a couple days. However, I figured I would still write my blog post on this topic. While his solution is a excellent one, I personally handle this another way most
of the time. Plus, it’s a commonly asked question that isn’t documented well enough on the web yet, so having another article on the web won’t hurt.
I can think
of four different ways to handle this, and depending on your situation you may lean towards any
of the four. Don’t let the choices overwhelm you though. Let’s keep it simple, Option 1 is what I use most
of the time, Option 2 is what Jeff proposed and is the safest option, and Option 3 and Option 4 need only be considered if you have a more unique situation. All four options will work for most situations.
Option 1 – CACHE_URL, single
rule
There is a server variable that has the protocol in it; {CACHE_URL}. This server variable contains the entire URL string (e.g. http://www.localtest.me:80/info.aspx?id=5) All we need to do is extract the HTTP or HTTPS and we’ll be set. This tends to be my preferred way to handle this situation.
Indeed, Jeff did briefly mention this in his blog post:
… you could use a condition on the CACHE_URL variable and a back reference in the rewritten URL. The problem there is that you then need to match all
of the conditions which could be a problem if your
rule depends on a logical “or” match for conditions.
Thus the problem. If you have multiple conditions set to “Match Any” rather than “Match All” then this option won’t work. However, I find that 95%
of all rules that I write use “Match All” and therefore, being the lazy administrator that I am I like this simple solution that only requires adding a single condition to a
rule. The caveat is that if you use “Match Any” then you must consider one
of the next two options.
Enough with the preamble. Here’s how it works. Add a condition that checks for {CACHE_URL} with a pattern
of “^(.+)://” like so:
How you have a back-reference to the part before the ://, which is our treasured HTTP or HTTPS. In URL Rewrite 2.0 or greater you can check the “Track capture groups across conditions”, make that condition the first condition, and you have yourself a back-reference
of {C:1}.
The “Redirect to www” example with support for maintaining the protocol, will become:
<rule name="Redirect to www" stopProcessing="true">
<match url="(.*)" />
<conditions trackAllCaptures="true">
<add input="{CACHE_URL}" pattern="^(.+)://" />
<add input="{HTTP_HOST}" pattern="^localtest\.me$" />
</conditions>
<action type="Redirect" url="{C:1}://www.localtest.me/{R:1}" />
</rule>
It’s not as easy as it would be if Microsoft gave us a built-in {HTTP_PROTOCOL} variable, but it’s pretty close.
I also like this option since I often create
rule examples for other people and this type
of rule is portable since it’s self-contained within a single
rule.
Option 2 – Using a Rewrite Map
For a safer
rule that works for both “Match Any” and “Match All” situations, you can use the Rewrite Map solution that Jeff proposed. It’s a perfectly good solution with the only drawback being the ever so slight extra effort to set it up since you need to create a rewrite map before you create the
rule. In other words, if you choose to use this as your sole method
of handling the protocol, you’ll be safe.
After you create a Rewrite Map called MapProtocol, you can use “{MapProtocol:{HTTPS}}” for the protocol within any
rule action. Following is an example using a Rewrite Map.
<rewrite>
<rules>
<rule name="Redirect to www" stopProcessing="true">
<match url="(.*)" />
<conditions trackAllCaptures="false">
<add input="{HTTP_HOST}" pattern="^localtest\.me$" />
</conditions>
<action type="Redirect"
url="{MapProtocol:{HTTPS}}://www.localtest.me/{R:1}" />
</rule>
</rules>
<rewriteMaps>
<rewriteMap name="MapProtocol">
<add key="on" value="https" />
<add key="off" value="http" />
</rewriteMap>
</rewriteMaps>
</rewrite>
Option 3 – CACHE_URL, Multi-rule
If you have many rules that will use the protocol, you can create your own server variable which can be used in subsequent rules. This option is no easier to set up than Option 2 above, but you can use it if you prefer the easier to remember syntax
of {HTTP_PROTOCOL} vs. {MapProtocol:{HTTPS}}.
The potential issue with this
rule is that if you don’t have access to the server level (e.g. in a shared environment) then you cannot set server variables without permission.
First, create a
rule and place it at the top
of the set
of rules. You can create this at the server, site or subfolder level. However, if you create it at the site or subfolder level then the HTTP_PROTOCOL server variable needs to be approved at the server level. This can be achieved in IIS Manager by navigating to URL Rewrite at the server level, clicking on “View Server Variables” from the Actions pane, and added HTTP_PROTOCOL. If you create the
rule at the server level then this step is not necessary.
Following is an example
of the first
rule to create the HTTP_PROTOCOL and then a
rule that uses it. The Create HTTP_PROTOCOL
rule only needs to be created once on the server.
<rule name="Create HTTP_PROTOCOL">
<match url=".*" />
<conditions logicalGrouping="MatchAll" trackAllCaptures="false">
<add input="{CACHE_URL}" pattern="^(.+)://" />
</conditions>
<serverVariables>
<set name="HTTP_PROTOCOL" value="{C:1}" />
</serverVariables>
<action type="None" />
</rule>
<rule name="Redirect to www" stopProcessing="true">
<match url="(.*)" />
<conditions logicalGrouping="MatchAll" trackAllCaptures="false">
<add input="{HTTP_HOST}" pattern="^localtest\.me$" />
</conditions>
<action type="Redirect" url="{HTTP_PROTOCOL}://www.localtest.me/{R:1}" />
</rule>
Option 4 – Multi-rule
Just to be complete I’ll include an example
of how to achieve the same thing with multiple rules. I don’t see any reason to use it over the previous examples, but I’ll include an example anyway. Note that it will only work with the “Match All” setting for the conditions.
<rule name="Redirect to www - http" stopProcessing="true">
<match url="(.*)" />
<conditions logicalGrouping="MatchAll" trackAllCaptures="false">
<add input="{HTTP_HOST}" pattern="^localtest\.me$" />
<add input="{HTTPS}" pattern="off" />
</conditions>
<action type="Redirect" url="http://www.localtest.me/{R:1}" />
</rule>
<rule name="Redirect to www - https" stopProcessing="true">
<match url="(.*)" />
<conditions logicalGrouping="MatchAll" trackAllCaptures="false">
<add input="{HTTP_HOST}" pattern="^localtest\.me$" />
<add input="{HTTPS}" pattern="on" />
</conditions>
<action type="Redirect" url="https://www.localtest.me/{R:1}" />
</rule>
Conclusion
Above are four working examples
of methods to call the protocol (HTTP or HTTPS) from the action
of a URL Rewrite
rule. You can use whichever method you most prefer. I’ve listed them in the order that I favor them, although I could see some people preferring Option 2 as their first choice. In any
of the cases, hopefully you can use this as a reference for when you need to use the protocol in the rule’s action when writing your URL Rewrite rules.
Further information:
Viewing all Server Variable for a site.
URL Parts available to URL Rewrite Rules
Further URL Rewrite articles
