.NET Tips and Tricks

Blog archive

URL Rewriting vs. HTTP Redirects

As Philip Jaske mentioned in his interview with Becky Nagel, one of the cool things in ASP.NET Core is the ability to rewrite incoming URLs to "fix up" a request. There are lots of reasons to do this, the primary one being that it gives you the flexibility to move server-side resources to new URLs: You just rewrite incoming requests using the old URLs to point to your new URLs.

But it does raise the question of when you should use URL Rewriting instead of sending an HTTP redirect to the client.

On the face of it, HTTP redirects are inefficient because they require you to send a redirect response to the client (network latency) with the new URL. That, in turn, requires the client to resend its request to the new URL provided in the redirect (even more network latency).

If the HTTP redirect is implemented with a 301 code (indicating that the change in URLs is permanent), then the client should automatically replace the original URL with the new, redirected URL when a request to the old URL is issued. That should eliminate the network latency on any future requests ... but the reality is that most hand-crafted consumers used to call Web Services aren't set up to do that.

HTTP rewriting should be more efficient than redirects because the client makes a single trip to the server: All the redirection is handled on the server. In addition, if you're using HTTP rewriting to support moving services to new URLs then you don't have to leave a client at the old URL just to return redirects. As an added feature, the client never sees the rewritten URL (unlike a redirect where the new URL is sent to the client), which may or may not be important to you. Effectively, the difference is similar to using a Server.Transfer versus a Server.Redirect in ASP.NET.

However, I say rewriting "should" be more efficient than redirects because Microsoft notes that if your rules get complex enough (or if you have "too many" rules), rewriting has the potential to slow performance on your site. If you use URL rewriting, then you'll want to monitor response times in case they start increasing.

You have other options. IIS has the URL Rewrite extension which is tightly coupled with IIS and will give you better performance. However, the URL Rewrite extension requires you to set up rewrite rules in IIS manager, moving rewriting out of your control as a developer and into the hands of your site administrator. ASP.NET Core's URL rewriting feature lets you keep your hands on the reins.

Posted by Peter Vogel on 06/18/2018


comments powered by Disqus

Featured

  • Oracle Leans on VS Code for New AI Dev Tooling

    Separate Oracle guides for Fusion AI Agent Studio and APEX development illustrate how VS Code has evolved from a popular editor into a foundation for an expanding range of developer experiences.

  • Speak Your Vibe: VS Code Insiders Talks Up Voice-Driven Development

    Microsoft is devoting an unusual share of the early VS Code 1.131 Insiders cycle to built-in dictation, Voice Mode and other speech-driven development features.

  • Visual Studio Insiders Further Refines Copilot Usage Tracking

    With devs reeling from usage-based billing sticker shock, Visual Studio 18.9 makes monthly Copilot plan usage easier to reach from the coding workflow while adding more cost information to a redesigned model picker.

  • VS Code 1.130 Expands Agent Host and Review Tools

    Microsoft's latest weekly VS Code release advances shared agent sessions, multi-file change review, chat visibility and terminal navigation

Subscribe on YouTube