Redirecting Routes in Web Servers: Why, How, and Where to Do It.

Blog Author : Rahul Khedekar

In my last blog, I explained how to upgrade old .NET applications to the latest .NET frameworks. Apart from upgrading to the latest versions, our goal was to break down a monolith into smaller independent services. We started with 2 services and upgraded them to .NET Core 8. There were some breaking changes in the upgraded .NET frameworks, mainly related to AutoMapper, Entity Framework, and MySQL connectors. As these were breaking changes, we had to thoroughly test all new APIs. Unit test cases would have been probably right approach, but existing APIs had very little unit test coverage. So we started creating test data for all APIs. But the problem was that there were some APIs that were used by some other services and didn’t have any documentation about these APIs. Also, these APIs used to consume quite complex JSON payloads, which had a lot of variations. So we could not test all cases. We decided to deploy them on the QA environment so that we can test these APIs with actual data.

We deployed these new APIs as V2. We wanted to route all requests coming to the old APIs to V2 without asking other API consumers to make changes at their end. We wanted to control switching between V1 and V2. So we decided to use redirect routes from V1 to V2.

In this blog, we’ll explore:

• Why you may need to redirect routes
• How redirection works in web browsers
• Common approaches across web servers
• How IIS handles redirection (Rewrite vs ARR)
• Alternatives using application-level middleware
• Best practices and when to use each option

Why Do We Need Route Redirection?

Here are some common scenarios:

1. API Versioning Redirect requests from /api/v1/… to /api/v2/….
2. Domain Consolidation or Change Redirect www.example.com to example.com, or move from http:// to https://.
3. Content Relocation URLs for resources like /blog/old-post might now live at /articles/new-post.
4. URL Normalization Remove trailing slashes, unify lowercase/uppercase URLs, etc.
5. SEO Optimization Prevent duplicate content and broken links.
6. Graceful Deprecation Allow backward compatibility while phasing out older endpoints.

How Web Browsers Handle Redirects

When a web browser receives an HTTP response with a redirection status code (like 301, 302, or 307), it automatically makes a follow-up request to the new location.

Key Redirect Status Codes:

301 : Moved Permanently

302 : Found (Temporary Redirect)

307 : Temporary Redirect

308 : Permanent Redirect

Redirecting in Different Web Servers

1. Apache (using .htaccess)

RewriteEngine On
RewriteRule ^old-url$ /new-url [R=301,L]        

2. NGINX

location /old-path {
    return 301 /new-path;
}        

3. Node.js/Express

app.get('/old-path', (req, res) => {
    res.redirect(301, '/new-path');
});        

4. Options in IIS (Internet Information Services)

1. URL Rewrite Module

Used for both redirects and rewrites.

Redirect (client-side):

Option 1: URL Rewrite (Redirect)

1. Need to install URL Rewrite Module
2. Redirects client to a different URL (i.e., client sees the new URL).
3. Use when the new API is hosted under the same domain or virtual path.
4. We can modify existing APIs to transparently redirect all requests coming to old APIs to the new ones without making any changes to the consumers of these APIs. We will have to modify the web.config of the Old APIs
5. Without ARR (Redirect only)

• Requests are redirected, not proxied
• Client sees the new URL in the browser or HTTP client.
• No additional IIS modules beyond URL Rewrite needed.

Example (web.config):

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.webServer>
    <rewrite>
      <rules>
        <!-- API 1: Redirect /api/v1/* to new API -->
        <rule name="Redirect Samples to new API" stopProcessing="true">
          <match url="^api/v1/(.*)" />
          <action type="Redirect" url="https://example.com/api/v2/{R:1}" redirectType="Found" />
        </rule>
      </rules>
    </rewrite>
  </system.webServer>
</configuration>        

1. Use redirectType="Found" for temporary (302) or "Permanent" for permanent (301) redirection.
2. Match patterns like ^path/v1/(.*) should align with your actual request structure.
3. You can write multiple rules. The order should be specific rules first, and then generic.
4. These can be used even when old and new APIs are on different subdomains or different IIS sites.

NOTE: URL Rewrite converts POST calls to GET. So if you are using POST calls, then ARR might be a better option.

Option 2: Reverse Proxy Using ARR (Application Request Routing)

1. Transparently proxies the old API endpoint to the new API endpoint
2. Keeps the original URL in the client’s request
3. Can be rolled back by disabling the rewrite rule

Steps for using ARR:

1. Install ARR and URL Rewrite modules in IIS.
2. Enable ARR proxying by following the steps.
3. Open IIS Manager.
4. Go to Server Node → Application Request Routing Cache.
5. On the right, click “Server Proxy Settings”.
6. Check ✅ “Enable proxy” and click Apply.
7. Configure a rewrite rule to forward requests.

Example (web.config):

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.webServer>
    <rewrite>
      <rules>
        <!-- API 1: Redirect /api/v1/* to new API -->
        <rule name="Redirect Samples to new API" stopProcessing="true">
          <match url="^api/v1/(.*)" />
          <action type="Rewrite" url="https://example.com/api/v2/{R:1}" />
        </rule>
      </rules>
    </rewrite>
  </system.webServer>
</configuration>        

With web.config, we can easily revert / change routes without re-deploying the application.

If you want to exclude a specific route from rerouting (don’t re-route auth routes) it can also be achieved using adding a condition like this

<rules>
    <rule name="Redirect Samples to new API" stopProcessing="true">
      <match url="^api/v1/(.*)" />
      <conditions>
        <add input="{REQUEST_URI}" pattern="^/api/v1/auth$" negate="true" />
      </conditions>
      <action type="Rewrite" url="https://example.com/api/v2/{R:1}" />
    </rule>
</rules>        

Middleware-Based Redirects (ASP.NET Core)

When using ASP.NET Core or another framework, you can configure middleware for dynamic routing logic:

app.Use(async (context, next) =>
{
    if (context.Request.Path.StartsWithSegments("/old"))
    {
        context.Response.Redirect("/new", permanent: true);
        return;
    }
    await next();
});        

This approach is suitable for:

• Custom logic
• Feature toggles (A/B testing)
• Real-time decision making

Application-only redirects (not accessible at the IIS level)

Which Approach Should You Use with IIS?

Conclusion

Redirection is a powerful tool when used correctly. Whether you’re optimizing for SEO, migrating APIs, or setting up reverse proxies, choosing the right redirection method based on your server and use case is crucial.

On IIS, the combination of URL Rewrite and ARR offers a flexible and robust mechanism for handling both simple and complex routing requirements. For application-specific behaviour, use middleware within your app logic.

On IIS, the combination of URL Rewrite and ARR offers a flexible and robust mechanism for handling both simple and complex routing requirements. For application-specific behaviour, use middleware within your app logic.