URL Rewrite vs. Redirect; What’s the difference?

IIS URL Rewrite has five different types of actions. They are: Rewrite, Redirect, Custom Response, Abort Request, and None. And if you have ARR (Application Request Routing) installed, then at the server level you’ll also see Route to Server Farm. The two most common actions are the Rewrite and the Redirect.

A common question that comes up for people who just start working with URL Rewrite is: what is the difference between a rewrite and a redirect? I remember wondering the same thing.

Fortunately there are some very clear cut-and-dry differences between then.

Simply put, a redirect is a client-side request to have the web browser go to another URL. This means that the URL that you see in the browser will update to the new URL.

A rewrite is a server-side rewrite of the URL before it’s fully processed by IIS. This will not change what you see in the browser because the changes are hidden from the user.

Let’s take a look at some other differences between them:

Redirect

Rewrite
Client-side Server-side
Changes URL in browser address bar Doesn’t change URL in browser address bar
Supports the following redirects:
301 – Permanent
302 – Found
303 – See Other
307 - Temporary		 Redirect status is non-applicable
Useful for search engine optimization by causing the search engine to update the URL. Also useful for search engines by using a friendly URL to hide a messy URL.
Example:
http://yourdomain.com to http://www.yourdomain.com in the browser		 Example:
http://localtest.me/articles/how-to-win-at-chess is a friendly URL for http://localtest.me/articles.aspx?name=now-to-win-at-chess
Can redirect to the same site or an unrelated site. Generally rewrites to the same site using a relative path, although if you have the ARR module installed you can rewrite to a different site. When you rewrite to a different site, URL Rewrite functions as a reverse proxy.
The page request flow is:
  • Browser requests a page
  • Server responds with a redirect status code
  • Browser makes 2nd request to the new URL
  • Server responds to the new URL
The page request flow is:
  • Browser requests a page
  • URL Rewrite rewrites the URL and makes request (still within IIS) for the updated page
Fiddler is a great tool to see the back and forth between the browser and server. Tools like Process Monitor and native IIS tools are best for getting under the covers.

Let’s take a look at some further examples:

A redirect changes the URL in the browser, like in the following examples:

Add a www to the domain name:image

Enforce trailing slashes or force to lowercase:image

Mapping of old to new URL after a site redesign, and let search engines know about it:
image

A rewrite doesn’t change the URL in the browser, but it does change the URL before the request is fully processed by IIS.

In the following example the URL is a friendly URL in the browser but the final URL seen by ASP.NET is not as friendly: 
image

Or you can use any part of the URL is a useful way by rewriting the URL. Again, the URL in the browser remains the same while the path or query string behind the scenes is changed:image

These are just some examples. Hopefully they clarify the difference between a rewrite and a redirect in URL Rewrite for IIS and help you with your URL Rewriting.

3 Comments

  • Can you clarify how IIS becomes a reverse proxy? This sounds like the Rewrite module itself is acting as the reverse proxy... is that really the case? Are there any hooks in ARR that would allow custom rewrite or pool selection logic analogous to an iRule?

  • Hi Keith,

    Indeed, when the ARR module is installed then you can use URL Rewrite as a reverse proxy.

    The way of managing the rules isn't generally handled in a script format like an iRule but you have a lot of flexibility using URL Rewrite and you can usually achieve what you need. And, if needed, you can extend URL Rewrite with custom .NET functionality to do pretty much anything that you want.

    ARR doesn't currently have any API hooks, but URL Rewrite does.

  • Basically from a networking point of it is an OSI model layer 7 routing for ARR just like F5 iRules.

    I would not think there is even anything that really need to extend the URLrewrite for with .NET code like Scott suggests that you cannot do via just the URLwriter.

Comments have been disabled for this content.