ASP.NET Core中的URL重写是通过Rewrite中间件在请求处理前修改URL的技术，用于优化SEO、提升用户体验、实现HTTPS重定向及旧链接兼容。通过AddRedirect、AddRewrite等方法可配置重定向和内部重写规则，自定义IRule还可实现基于请求头等复杂逻辑，需注意中间件顺序、正则效率与重定向循环问题。
ASP.NET Core中的URL重写，简单来说，就是一种在服务器端修改传入请求URL的技术，在请求被ASP.NET Core应用程序处理之前，我们就可以对它进行“变脸”。它允许我们改变用户在浏览器地址栏看到的URL，或者在内部将一个URL映射到另一个URL，而用户可能对此毫无察觉。这对于维护网站的良好结构、优化搜索引擎（SEO）以及提供更友好的用户体验至关重要。
解决方案
在ASP.NET Core中设置URL重写，我们主要通过内置的
Microsoft.AspNetCore.Rewrite
中间件来实现。这个中间件提供了一套灵活的API，让我们能够定义各种重写规则。
首先，确保你的项目引用了
Microsoft.AspNetCore.Rewrite
NuGet包。通常，它在ASP.NET Core项目中是默认包含的，但如果遇到问题，可以手动添加。
接下来，你需要在应用的启动配置中（通常是
Startup.cs
的
Configure
方法，或者在.NET 6+的
Program.cs
中）注册并配置这个中间件。重写中间件应该在处理静态文件、认证、授权和路由等其他中间件之前被调用，因为它需要首先修改传入的URL。
以下是一个基本的配置示例：
// 在 .NET 6+ 的 Program.cs 文件中using Microsoft.AspNetCore.Rewrite;var builder = WebApplication.CreateBuilder(args);// 添加服务到容器builder.Services.AddRazorPages(); // 假设你使用Razor Pagesvar app = builder.Build();// 配置重写规则var options = new RewriteOptions() // 强制将所有HTTP请求重定向到HTTPS .AddRedirectToHttpsPermanent() // 将旧的URL路径重定向到新的路径 // 例如，/old-path 会被永久重定向到 /new-path .AddRedirect("old-path/?$", "new-path", 301) // 使用正则表达式进行重写 // 例如，/products/123 会在内部重写为 /item?id=123，但浏览器地址栏不变 .AddRewrite(@"^products/(d+)$", "item?id=$1", true);app.UseRewriter(options);// 其他中间件的顺序很重要，重写通常放在前面if (!app.Environment.IsDevelopment()){ app.UseExceptionHandler("/Error"); app.UseHsts();}app.UseStaticFiles();app.UseRouting();app.UseAuthorization();app.MapRazorPages();app.Run();
在这个例子中：
AddRedirectToHttpsPermanent()
是一个非常方便的方法，它会捕获所有非HTTPS请求，并以301（永久重定向）状态码将其重定向到HTTPS版本。这对于网站的安全性至关重要。
AddRedirect("old-path/?$", "new-path", 301)
定义了一个从
/old-path
（可选地包含或不包含斜杠）到
/new-path
的永久重定向。
301
状态码告诉浏览器和搜索引擎这个改变是永久的。
AddRewrite(@"^products/(d+)$", "item?id=$1", true)
则是一个内部重写规则。当用户访问
/products/123
这样的URL时，服务器会在内部将其处理为
/item?id=123
，但用户在浏览器地址栏看到的仍然是
/products/123
。
true
参数表示这是一个
Rewrite
而不是
Redirect
。
你可以根据自己的需求添加更多的
AddRedirect
、
AddRewrite
甚至自定义规则。记住，这些规则是按照它们在
RewriteOptions
中添加的顺序进行处理的，所以规则的顺序有时会非常关键。
为什么我们需要URL重写？它能解决哪些实际问题？
说实话，我个人觉得URL重写在现代Web开发中几乎是不可或缺的。它不只是一个“锦上添花”的功能，而是解决了一系列实实在在的问题。
首先，从搜索引擎优化（SEO）的角度来看，简洁、语义化的URL对排名有着直接的影响。一个URL像
/products/red-shoes
肯定比
/viewitem.aspx?categoryid=1&itemid=123
更容易被搜索引擎理解和索引。URL重写能帮助我们把那些由底层框架或数据库结构生成的复杂、参数堆砌的URL，转换成对用户和搜索引擎都友好的形式。这就像给你的网站穿上了一件更体面、更易识别的外衣。
其次，它极大地提升了用户体验。试想一下，如果你想分享一个产品链接给朋友，是复制一个干净利落的短链接好，还是一个长串的、充满问号和等号的链接好？显然是前者。而且，用户更容易记住和手动输入一个结构化的URL。当网站进行改版或内容迁移时，旧的链接很容易失效，导致大量的404错误。通过URL重写，我们可以将这些旧链接优雅地重定向到新位置，避免用户遇到“死胡同”，这对于网站的信誉和用户留存至关重要。我以前就遇到过网站改版后大量旧链接失效，用户抱怨连连的情况，那时候URL重写简直是救命稻草。
再者，安全性也是一个不容忽视的方面。强制HTTPS就是最典型的应用。通过
AddRedirectToHttpsPermanent()
，我们可以确保所有流量都通过加密连接传输，这不仅保护了用户数据，也是现代网站的基本要求。
最后，它在技术维护和灵活性方面提供了巨大帮助。比如，你可以用它来处理A/B测试的流量分发，或者在不改变后端代码的情况下，为某些特定用户或请求头提供不同的内容。这给了开发者在不触及核心业务逻辑的情况下，调整网站行为的能力。
URL重写和URL路由有什么区别？它们是怎样协同工作的？
这是一个经常让人混淆的问题，但理解它们之间的差异和协作方式非常关键。在我看来，它们就像流水线上的两个不同但紧密合作的工位。
URL重写（URL Rewriting）发生在请求处理的早期阶段，它主要关注的是修改传入的URL本身。你可以把它想象成一个“门卫”或者“翻译官”。当一个HTTP请求到达服务器时，URL重写中间件会首先检查这个请求的URL，并根据预设的规则对其进行潜在的修改。这个修改可以是内部的（用户在浏览器地址栏看不到变化），也可以是外部的（通过301/302重定向，用户浏览器地址栏会更新）。它的核心目标是改变请求的路径、查询字符串甚至协议，以便后续的组件能接收到一个“处理过”的URL。
而URL路由（URL Routing）则发生在重写之后，它的任务是将（可能已经被重写过的）URL映射到应用程序中的特定处理程序。路由是ASP.NET Core的核心功能之一，它决定了哪个控制器动作、哪个Razor Page或哪个Endpoint应该来响应这个请求。你可以把路由看作一个“调度员”，它根据URL的结构，将请求分发到正确的代码逻辑。
它们之间的协同工作是这样的：
用户在浏览器中输入或点击一个URL，比如
/old-product-page
。请求到达ASP.NET Core应用。URL重写中间件首先介入。如果有一个规则将
/old-product-page
重定向到
/new-product-details
，那么这个重定向就会发生。用户浏览器会收到301响应，然后自动发起对
/new-product-details
的新请求。假设现在请求的URL是
/new-product-details
（或者如果重写是内部的，请求的URL被内部修改为
/api/products?id=xyz
）。URL路由中间件接着介入。它会分析当前的URL（例如
/new-product-details
），并根据你定义的路由规则（比如
app.MapControllerRoute(name: "default", pattern: "{controller=Home}/{action=Index}/{id?}");
或
app.MapRazorPages();
），找到对应的控制器动作或Razor Page来处理这个请求。最终，找到的控制器动作或Razor Page执行业务逻辑，并返回响应。
所以，重写是预处理，它改变了请求的“面貌”；路由是分发，它决定了请求的“去向”。它们各司其职，共同确保了请求能被正确、高效地处理。
在ASP.NET Core中进行URL重写时，有哪些常见的陷阱和性能考量？
在URL重写这个领域，虽然它功能强大，但如果不小心，也容易踩坑。我个人在处理一些复杂的重写规则时，就遇到过不少头疼的问题。
一个最常见的陷阱就是中间件的顺序问题。我在前面提过，重写中间件的放置位置至关重要。如果它被放在了静态文件中间件之后，那么对静态文件的重写规则可能就不会生效。同样，如果它在认证或授权中间件之后，那么这些中间件可能已经处理了原始的URL，而不是你期望的重写后的URL。这种顺序错误往往很难调试，因为表面上看起来一切正常，但就是达不到预期效果。解决办法就是：重写规则通常要尽可能地放在请求管道的前面。
正则表达式的复杂性和效率是另一个需要警惕的地方。虽然正则表达式提供了极大的灵活性，但编写不当的正则表达式可能会导致性能瓶颈，尤其是在高并发的场景下。一个过于宽泛或效率低下的正则，可能会对每个传入请求都进行大量的计算。我曾经写过一个正则，因为一个微小的疏忽，导致它在某些情况下匹配了不该匹配的URL，进而引发了意想不到的重定向循环。所以，测试你的正则表达式，并尽量让它们精确且高效，是基本功。
无限重定向循环也是一个非常危险的陷阱。这通常发生在重写规则相互冲突或逻辑不严谨时。例如，你可能有一个规则将
/page-a
重定向到
/page-b
，而另一个规则又将
/page-b
重定向回
/page-a
，这就会导致浏览器陷入无限循环，最终报错。调试这种问题需要耐心，通常需要仔细检查所有相关的重写规则，并确保它们不会形成闭环。
从性能考量的角度看，每一次重写操作都会增加一点点的处理开销。对于大多数应用来说，这点开销微不足道。但如果你的网站有数以万计的重写规则，或者你的正则表达式非常复杂，那么累积起来的开销就可能变得显著。此外，HTTP缓存也会受到重写的影响，尤其是永久重定向（301）。浏览器和CDN会长时间缓存301重定向，这意味着如果你改变了一个301规则，用户可能需要很长时间才能看到更新。对于临时重定向（302），缓存行为则不同，它通常不会被永久缓存。因此，选择正确的重定向状态码非常重要。
最后，调试重写规则有时会很棘手。ASP.NET Core的日志系统可以帮助你，但你可能需要添加自定义日志来追踪重写中间件的具体行为。我发现最好的办法是先在本地用少量、简单的规则进行测试，逐步增加复杂性，并利用像Regex101这样的在线工具来测试正则表达式。
如何实现更复杂的URL重写规则，例如基于请求头或自定义逻辑？
当内置的
AddRedirect
或
AddRewrite
方法无法满足你的需求时，ASP.NET Core的重写中间件提供了更高级的扩展点：实现自定义的
IRule
接口。这为我们打开了基于请求头、Cookie、查询参数甚至外部数据源等任意自定义逻辑进行重写的大门。
要实现自定义规则，你需要创建一个类，实现
Microsoft.AspNetCore.Rewrite.IRule
接口，并实现其
ApplyRule
方法。在这个方法中，你可以完全掌控请求的上下文，并决定是否进行重写或重定向。
这是一个基于
User-Agent
请求头进行重写的例子：
using Microsoft.AspNetCore.Rewrite;using Microsoft.AspNetCore.Http;using System.Threading.Tasks;public class MobileRedirectRule : IRule{ private readonly string _mobilePath; private readonly PathString _excludePath; public MobileRedirectRule(string mobilePath, string excludePath) { _mobilePath = mobilePath; _excludePath = new PathString(excludePath); } public void ApplyRule(RewriteContext context) { var request = context.HttpContext.Request; // 如果请求路径已经是移动版路径，或者我们明确要排除的路径，则不进行重写 if (request.Path.StartsWithSegments(_mobilePath) || request.Path.StartsWithSegments(_excludePath)) { return; } // 检查User-Agent是否包含常见的移动设备标识 if (request.Headers["User-Agent"].ToString().Contains("Mobile") || request.Headers["User-Agent"].ToString().Contains("Android") || request.Headers["User-Agent"].ToString().Contains("iPhone")) { // 构建新的移动版URL var newPath = new PathString(_mobilePath).Add(request.Path); var newUrl = $"{request.Scheme}://{request.Host}{newPath}{request.QueryString}"; // 执行302临时重定向到移动版页面 context.Result = RuleResult.ForRedirect(newUrl, 302); context.HttpContext.Response.Headers["Location"] = newUrl; // 确保Location头被设置 context.HttpContext.Response.StatusCode = 302; } }}
然后，在
Program.cs
（或
Startup.cs
）中注册这个自定义规则：
// ... 其他配置var options = new RewriteOptions() .AddRedirectToHttpsPermanent() .Add(new MobileRedirectRule("/m", "/admin")); // 如果是移动设备，重定向到/m/原路径，但/admin路径除外app.UseRewriter(options);// ... 其他中间件
在这个
MobileRedirectRule
中，我们：
在构造函数中传入了移动版路径（例如
/m
）和需要排除的路径（例如
/admin
），避免重定向循环或不必要的重定向。在
ApplyRule
方法中，我们首先检查当前请求是否已经位于移动版路径或排除路径，如果是则直接返回，不进行任何操作。接着，我们通过
request.Headers["User-Agent"]
来获取用户代理信息，判断是否为移动设备。如果判断为移动设备，我们构建一个新的URL，将原始路径前加上
/m
，并保留查询字符串。最后，通过
context.Result = RuleResult.ForRedirect(...)
设置重定向结果，并手动设置
Location
头和
StatusCode
。这里使用302（临时重定向），因为用户可能希望在桌面设备上访问完整版网站。
这种自定义规则的强大之处在于，你可以访问
RewriteContext
中的
HttpContext
，这意味着你可以检查几乎所有请求相关的属性：
Request.Path
、
Request.QueryString
、
Request.Headers
、
Request.Cookies
，甚至是
Request.Method
。你可以根据这些信息编写非常精细和复杂的逻辑，比如：
根据特定的Cookie值重定向到A/B测试页面。根据请求的
Accept-Language
头重定向到不同的语言版本站点。根据外部API的响应来决定是否重写或重定向。
这种灵活性使得URL重写不仅仅是路径映射，更成为了一个强大的请求预处理工具。当然，随着复杂度的增加，测试和维护的难度也会相应提高，所以务必做好充分的单元测试和集成测试。
以上就是ASP.NET Core中的URL重写是什么？如何设置？的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1439697.html
微信扫一扫 
支付宝扫一扫 
