URL Rewrite/Redirect for Asp.NET API and Azure Web Apps

Mahdi Karimipour

6 min readJun 25, 2021

Context

There are a few use cases that you might consider using URL rewrite/redirect in Asp.NET applications:

Transferring old content to new content between URLs for SEO purposes
Having a new domain which you’d want to redirect traffic from your old domain
and if your website simply support multiple domains, but you want to consolidate all your traffic in one domain for SEO purposes
Having more meaningful (user friendly) URLs by replacing shortened URLs/translating identifiers
Redirect from Http to Https
Redirect from www version of your website to non-www or vice-versa

By the way, this topic belongs to the series to set up an Asp.NET API for production use.

URL Rewrite vs URL Redirect

Rewrite: happens when the server changes the URL to a new URL within the same request. Hence the browser won’t know if the rewrite happened. On the server side however, all the middleware modules in the request pipelines after the rewrite would see the new request URL.

To make things clearer, here is a basic example of how you would implement a rewrite through Asp.Net Core middleware:

Redirect: Redirect happens when the server sends a header back to browser through a 301/302 (permanent move), asking the browser to initiate a new request to the server with the new URL.

and here is a basic example of URL Redirect through the same middleware structure, which you could use to navigate entirely from the old URL to a new one, which could also be external.

Tip: When it comes down to SEO, it is recommended that you consolidate all your traffic into one domain with a permanent redirect (301). You are basically telling the search engine that the old URL is deprecated now.

Depending on what you are trying to achieve, you might choose rewrite or redirect. In this article we will cover how to achieve them using various options.

Solutions

In Asp.NETcore there are various approaches you can implement URL Rewrite (or redirect):

Using URL Rewriting Middleware and Microsoft.AspNetCore.Rewrite library
Using IIS configurations through web.config or a remote session through IIS manager
Using various redirect helper functions inside your controllers

Solution 1: Asp.Net Core Middleware

We have already covered a basic implementation of redirect/rewrite through middleware, however we could have a more maintainable implementation by using Microsoft.AspNetCore.Rewrite

Example: Permanent Redirect

Within that library, there is a extension method for IApplicationBuilder called UseRewriter, which accepts a RewriteOptions containing your redirect/rewrite rules. The below redirects all requests to port 5001 permanently by sending a 301 status code.

Example: Http to Https

Using the same library, you can redirect requests to insecure endpoints, to secure equvalent with port 443.

Example: Basic URL Rewrite

Rewriting a simple URL:

or using regex to match specific URLs:

Custom URL Rewrite Rule

We are not limited to the functions and templates provided by the RewriteOptions. You can indeed write your own custom rewrite rules using Microsoft.AspNetCore.Rewrite.IRule. First we need to implement the interface, like below

and then inject your own logic into for the rule

followed by adding the rule to the collection:

Note
Configuration, plumbing and troubleshooting your software foundation take a considerable amount of time in your product development. Consider using Pellerex which is a complete foundation for your enterprise software products, providing source-included Identity and Payment functions across UI (React), API (.NET), Pipeline (Azure DevOps) and Infrastructure (Kubernetes).

Solution 2: Using Controller Actions

Perhaps one of the simplest ways to implement URL redirect is through the controller actions, by simply call the redirect method. The downside with this approach however is that it is just limited to one action, and it needs to be repeated for other actions as well, while the IIS or middleware approach applies to the entire application in one central spot.

Solution 3: By Configuring IIS

You can configure your IIS through IIS Manager by connecting to the server or site or use web.config deployed as part of your application:

I personally prefer the web.config approach as it stays with your application regardless of where you deploy it, and you will have one less manual step to take care of in case you decided to move your application elsewhere or have a new installation for any reason

On top of that, if you are deploying your app using Azure Web Apps, Microsoft has discontinued supporting IIS manager to configure your Azure Web App.

Web.Config

Although I understand you are using appsettings.json to store the configuration of your Asp.Net core web app, you can still have web.config with redirect configurations in there.

This is what I have personally been using to redirect one of my apps (deployed through Azure Web Apps) from an alternative domain to the main one.

This basically tells IIS, to redirect all the traffic to the NewDomain.com, and stop, when the redirected domain matched NewDomain.com by the negate condition.

Using this solution, all you need to do is to include web.config at the root of your application, with BuildAction set to Content.

Having this configuration in place, the next time you visit the old domain associated with your Azure Web App, the traffic will be directed to NewDomain.com.

As an exmaple, below web.config will redirect all traffic from https://technologyleads.com.au to https://technologyleads.io, because initially we started with .com.au and eventually as we had global products, we purchased .io domain and needed to consolidate all our traffic to .io for SEO reasons.

Note that the condition (the negate condition to be specific) tells IIS where to stop the redirect process. If that is not set properly IIS will keep redirecting in a loop, and it will fail eventually.

In order to detect that, you can use a tool like Redirect Checker to see what is happening with your redirects. In our case, you can see that technologyleads.com.au is redirected to technologyleads.io, and it is done after that, as the negate condition kicks in.

Pellerex Foundation: For Your Next Enterprise Software

How are you building your current software today? Build everything from scratch or use a foundation to save on development time, budget and resources? For an enterprise software MVP, which might take 8–12 months with a small team, you might indeed spend 6 months on your foundation. Things like Identity, Payment, Infrastructure, DevOps, etc. they all take time, while contributing not much to your actual product. These features are needed, but they are not your differentiators.

Pellerex does just that. It provides a foundation that save you a lot development time and effort at a fraction of the cost. It gives you source-included Identity, Payment, Infrastructure, and DevOps to build Web, Api and Mobile apps all-integrated and ready-to-go on day 1.

Check out Pellerex and talk to our team today to start building your next enterprise software fast.