Azure App Services: Understanding URL Re-write

More often than not, we come across requirements with our Azure App Service where we may need to enforce HTTPS, redirect from *.com to *.in, redirect  from to and so on...
The requirements can be tricky sometimes. Formulating such rules, and ensuring they're both logically and syntactically correct can be a little time consuming. I’ve shared below a few pointers that you can use to formulate such re-write rules and avoid your site from going offline due to trial and errors on a live site.
Some background on URL Re-write:
Azure App Service (PaaS) is nothing but IIS Servers placed on the cloud. Therefore, URL Re-write on Azure App Service works a lot like IIS .
Where does URL-Rewrite fit in IIS Architecture?

Where does URL-Rewrite fit in IIS Architecture

URL-Rewrite's place in IIS Architecture

How is re-write different from Redirect?


Happens at the Server Side Happens at the Client Side
Browser does not see new URL in address bar Browser sees a different URL In address bar
Client unaware if content is served from a re-written URL Client aware of a redirect URL.
You can re-write to and the client still sees the friendly URL You can redirect from to and the browser shows the news URL
Generally for a resource within same site. Can be redirected to same site or different site altogether.
Request Handling (REWRITE): which you want to point to

  1. Client calls:
  2. URL Rewrite Module sees a rule match and provides new rewritten URL to IIS i.e. and Server makes request for that URL within IIS.
  3. Server responds with 200 OK for original URL but with content from rewritten URL. (address bar shows original URL and client does not know that you are serving content from different URL)


Request Handling (REDIRECT): to redirect to

1.       Client calls:

2.       URL Rewrite Module sees a rule match for client URL and gives new redirect URL.

3.       Server responds with 301 with new URL for client to call

4.       Client calls new URL

5.       Server responds with 200 OK for new URL. (address bar shows new URL)


Common Scenarios:
1. Enforce HTTPS:
  <rule name="HTTP_TO_HTTPS" stopProcessing="true">
<match url=".*" />
<add input="{HTTP_HOST}" pattern="^$" />
<add input="{HTTPS}" pattern="OFF" />
<action type="Redirect" url="https://{C:0}/{R:0}" />
NOTE:  It is important to use Redirect here since the request needs to come back to the server over HTTPS.
2. In case there are multiple domains associated with the Web App and you want to enforce HTTPS on all of them:
<rule name=" HTTP_TO_HTTPS " stopProcessing="true">
<match url=".*" />
<add input="{HTTPS}" pattern="OFF" />
<add input="{HTTP_HOST}" pattern="(^$)|(^$)" />
<action type="Redirect" url="https://{C:0}/{R:0}" />
3. Redirection from root domain to sub-domain:
<rule name="Root_To_Subdomain " stopProcessing="true">
<match url=".*" />
<add input="{HTTP_HOST}" pattern="^$" />
<action type="Redirect" url="http://www.{C:0}/{R:0}" />
NOTE:  It is important to use Redirect (send the modified request back to the client) here since it is necessary to validate if the sub-domain is mapped to the same Web App.
4. Redirect from to , to, to , to and so on…
  <rule name="Change-TLD" stopProcessing="true">
<match url=".*" />
<conditions logicalGrouping="MatchAny">
<add input="{HTTP_HOST}" pattern="(.*).com" />
<add input="{HTTP_HOST}" pattern="(.*).org" />
<add input="{HTTP_HOST}" pattern="(.*).net" />
<action type="Redirect" url="http://{C:1}.in/{R:0}" />
a. We can use (.*).com here to accommodate both and
b. logicalGrouping="MatchAny" will only match one of the conditions that succeed it. logicalGrouping="MatchAll" by default.
Some useful stopping Conditions:
Stopping conditions are very important in order to avoid too-many-redirects caused due the same request being processed every time (Re-write --> Send to client --> Client requests re-written URL from the server --> No Appropriate stopping condition --> Rule processed again --> Re-write…and this cycle repeats)
To avoid such scenarios, you want to formulate rules that have a logical stopping condition. The below pointers may be useful:
<add input="{HTTPS}" pattern="OFF" /> Process the rule if the request does not come over HTTPS
<add input="{HTTPS}" pattern="ON" negate="true" /> Process the rule if the request comes over HTTP only. Same as above.
<add input="{HTTP_HOST}" pattern="^$" negate="true" /> Process the rule for all other domains except for
Want to know how to test your rules for perfection while avoiding production downs? A blog on that is coming soon..

Comments (0)

Skip to main content