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
