phpiisurlrewrite技巧_ASPNET Core 中的 URL 重写中心件

文章目录 [+]

URL 重定向涉及客户端操作，指示客户端访问与客户端最初要求地址不同的资源。
这须要来回做事器。
客户端对资源发出新要求时，返回客户真个重定向 URL 会涌如今浏览器地址栏。

如果 /resource 被重定向到 /different-resource，则做事器作出相应，指示客户端应在 /different-resource 获取资源，所供应的状态代码指示重定向是临时的还是永久的。

phpiisurlrewrite技巧_ASPNET Core 中的 URL 重写中心件

将要求重定向到不同 URL 时，通过利用相应指定状态代码来指示重定向是永久还是临时：

（图片来自网络侵删）

如果资源有一个新的永久性 URL，并且你希望指示客户端所有将来的资源要求都利用新 URL，则利用“301 (永久移动)”状态代码。
收到 301 状态代码时，客户端可能会缓存相应并重用这段代码。
“302 (找到)”状态代码用于后列情形：重定向操作是临时的或常日会发生变革。
302 状态代码向客户端指示不存储 URL 并在将来利用。

有关状态代码的详细信息，请参阅 RFC 2616：状态代码定义。

URL 重写是做事器端操作，它从与客户端要求的资源地址不同的资源地址供应资源。
重写 URL 不须要来回做事器。
重写的 URL 不会返回客户端，也不会涌如今浏览器地址栏。

如果 /resource 重写到 /different-resource，做事器会在内部提取并返回 /different-resource 处的资源。

只管客户端可能能够检索已重写 URL 处的资源，但是，客户端发出要求并收到相应时，并不知道已重写 URL 处存在的资源。

URL 重写示例运用

可利用示例运用理解 URL 重写中间件的功能。
该运用程序运用重定向和重写规则，并显示多个方案的重定向或重写的 URL。

何时利用 URL 重写中间件

如果无法利用以下方法，请利用 URL 重写中间件：

在 Windows Server 上利用带 IIS 的 URL 重写模块在 Apache 做事器上利用 Apache mod_rewrite 模块Nginx 上的 URL 重写

此外，如果运用程序在 HTTP.sys 做事器（旧称 WebListener）上托管，请利用中间件。

利用 IIS、Apache 和 Nginx 中的基于做事器的 URL 重写技能的紧张缘故原由：

中间件不支持这些模块的完全功能。
做事器模块的一些功能不适用于 ASP.NET Core 项目，例如 IIS 重写模块的 IsFile 和 IsDirectory 约束。
在这些情形下，请改为利用中间件。
中间件性能与模块性能不匹配。
基准测试是确定哪种方法会最大程度降落性能或降落的性能是否可忽略不计的唯一方法。
Package

URL 重写中间件由 Microsoft.AspNetCore.Rewrite 包供应，该包隐式包含在 ASP.NET Core 运用中。

扩展和选项

通过利用扩展方法为每条重写规则创建 RewriteOptions 类的实例，建立 URL 重写和重写定向规则。
按所需的处理顺序链接多个规则。
利用 UseRewriter 将 RewriteOptions 添加到要求管道时，它会被通报到 URL 重写中间件：

public void Configure(IApplicationBuilder app){ using (StreamReader apacheModRewriteStreamReader = File.OpenText("ApacheModRewrite.txt")) using (StreamReader iisUrlRewriteStreamReader = File.OpenText("IISUrlRewrite.xml")) { var options = new RewriteOptions() .AddRedirect("redirect-rule/(.)", "redirected/$1") .AddRewrite(@"^rewrite-rule/(\d+)/(\d+)", "rewritten?var1=$1&var2=$2", skipRemainingRules: true) .AddApacheModRewrite(apacheModRewriteStreamReader) .AddIISUrlRewrite(iisUrlRewriteStreamReader) .Add(MethodRules.RedirectXmlFileRequests) .Add(MethodRules.RewriteTextFileRequests) .Add(new RedirectImageRequests(".png", "/png-images")) .Add(new RedirectImageRequests(".jpg", "/jpg-images")); app.UseRewriter(options); } app.UseStaticFiles(); app.Run(context => context.Response.WriteAsync( $"Rewritten or Redirected Url: " + $"{context.Request.Path + context.Request.QueryString}"));}将非 www 重定向到 www

三个选项许可运用将非 www 重新定向到 www：

AddRedirectToWwwPermanent：如果要求是非 www，则将要求永久重定向到 www 子域。
利用 Status308PermanentRedirect 状态代码进行重定向。
AddRedirectToWww：如果传入要求是非 www，则将要求重定向到 www 子域。
利用 Status307TemporaryRedirect 状态代码进行重定向。
重载许可供应相应状态代码。
利用 StatusCodes 类的字段实现状态代码分配。
URL 重定向

利用 AddRedirect 将要求重定向。
第一个参数包含用于匹配传入 URL 路径的正则表达式。
第二个参数是更换字符串。
第三个参数（如有）指定状态代码。
如不指定状态代码，则状态代码默认为“302 (已找到)”，指示资源暂时移动或更换。

在启用了开拓职员工具的浏览器中，向路径为 /redirect-rule/1234/5678 的示例运用发出要求。
正则表达式匹配 redirect-rule/(.) 上的要求路径，且该路径会被 /redirected/1234/5678 替代。
重定向 URL 以“302 (已找到)”状态代码发回客户端。
浏览器会在浏览器地址栏中涌现的重定向 URL 上发出新要求。
由于示例运用中的规则都不匹配重定向 URL：

第二个要求从运用程序收到“200 (正常)”相应。
相应正文显示了重定向 URL。

重定向 URL 时，系统将向做事器进行一次来回。

警告

建立重定向规则时务必小心。
系统会根据运用的每个要求（包括重定向后的要求）对重定向规则进行评估。
很随意马虎便会意外创建无限重定向循环。

原始要求：/redirect-rule/1234/5678

括号内的表达式部分称为“捕获组”。
表达式的点 (.) 表示匹配任何字符。
星号 () 表示零次或多次匹配前面的字符。
因此，URL 的末了两个路径段 1234/5678 由捕获组 (.) 捕获。
在要求 URL 中供应的位于 redirect-rule/ 之后的任何值均由此单个捕获组捕获。

在更换字符串中，将捕获组注入带有美元符号 ($)、后跟捕获序列号的字符串中。
获取的第一个捕获组值为 $1，第二个为 $2，并且正则表达式中的其他捕获组值将依次连续排列。
示例运用的重定向规则正则表达式中只有一个捕获组，因此更换字符串中只有一个注入组，即 $1。
如果运用此规则，URL 将变为 /redirected/1234/5678。

URL 重定向到安全的闭幕点

利用 AddRedirectToHttps 将 HTTP 要求重定向到采取 HTTPS 协议的相同主机和路径。
如不供应状态代码，则中间件默认为“302(已找到)”。
如果不供应端口：

中间件默认为 null。
方案变动为 https（HTTPS 协议），客户端访问端口 443 上的资源。

下面的示例演示如何将状态代码设置为“301(永久移动)”并将端口变动为 5001。

public void Configure(IApplicationBuilder app){ var options = new RewriteOptions() .AddRedirectToHttps(301, 5001); app.UseRewriter(options);}

利用 AddRedirectToHttpsPermanent 将不屈安的要求重定向到端口 443 上的采取安全 HTTPS 协议的相同主机和路径。
中间件将状态代码设置为“301 (永久移动)”。

public void Configure(IApplicationBuilder app){ var options = new RewriteOptions() .AddRedirectToHttpsPermanent(); app.UseRewriter(options);}

当重定向到安全的闭幕点并且不须要其他重定向规则时，建议利用 HTTPS 重定向中间件。
有关详细信息，请参阅逼迫利用 HTTPS主题。

示例运用能够演示如何利用 AddRedirectToHttps 或 AddRedirectToHttpsPermanent。
将扩展方法添加到 RewriteOptions。
在任何 URL 上向运用发出不屈安的要求。
肃清自署名证书不受信赖的浏览器安全警告，或创建例外以信赖证书。

利用 AddRedirectToHttps(301, 5001) 的原始要求：http://localhost:5000/secure

利用 AddRedirectToHttpsPermanent 的原始要求：http://localhost:5000/secure

URL 重写

利用 AddRewrite 创建重写 URL 的规则。
第一个参数包含用于匹配传入 URL 路径的正则表达式。
第二个参数是更换字符串。
第三个参数 skipRemainingRules: {true|false} 指示如果当前规则适用，中间件是否要跳过其他重写规则。

原始要求：/rewrite-rule/1234/5678

Apache mod_rewrite

利用 AddApacheModRewrite 运用 Apache mod_rewrite 规则。
请确保将规则文件与运用一起支配。
有关 mod_rewrite 规则的详细信息和示例，请参阅 Apache mod_rewrite。

StreamReader 用于读取 ApacheModRewrite.txt 规则文件中的规则：

示例运用将要求从 /apache-mod-rules-redirect/(.\) 重定向到 /redirected?id=$1。
相应状态代码为“302 (已找到)”。

# Rewrite path with additional sub directoryRewriteRule ^/apache-mod-rules-redirect/(.) /redirected?id=$1 [L,R=302]

原始要求：/apache-mod-rules-redirect/1234

中间件支持下列 Apache mod_rewrite 做事器变量：

CONN_REMOTE_ADDRHTTP_ACCEPTHTTP_CONNECTIONHTTP_COOKIEHTTP_FORWARDEDHTTP_HOSTHTTP_REFERERHTTP_USER_AGENTHTTPSIPV6QUERY_STRINGREMOTE_ADDRREMOTE_PORTREQUEST_FILENAMEREQUEST_METHODREQUEST_SCHEMEREQUEST_URISCRIPT_FILENAMESERVER_ADDRSERVER_PORTSERVER_PROTOCOLTIMETIME_DAYTIME_HOURTIME_MINTIME_MONTIME_SECTIME_WDAYTIME_YEARIIS URL 重写模块规则

若要利用适用于 IIS URL 重写模块的同一规则集，利用 AddIISUrlRewrite。
请确保将规则文件与运用一起支配。
当在 Windows Server IIS 上运行时，请勿指示中间件利用运用的 web.config 文件。
利用 IIS 时，应将这些规则存储在运用的 web.config 文件之外，以避免与 IIS 重写模块发生冲突。
有关 IIS URL 重写模块规则的详细信息和示例，请参阅 Using Url Rewrite Module 2.0（利用 URL 重写模块 2.0）和 URL Rewrite Module Configuration Reference（URL 重写模块配置引用）。

StreamReader 用于读取 IISUrlRewrite.xml 规则文件中的规则：

示例运用将要求从 /iis-rules-rewrite/(.) 重写为 /rewritten?id=$1。
以“200 (正常)”状态代码作为相应发送到客户端。

XML复制

<rewrite> <rules> <rule name="Rewrite segment to id querystring" stopProcessing="true"> <match url="^iis-rules-rewrite/(.)$" /> <action type="Rewrite" url="rewritten?id={R:1}" appendQueryString="false"/> </rule> </rules></rewrite>

原始要求：/iis-rules-rewrite/1234

如果有配置了做事器级别规则（可对运用产生不利影响）的活动 IIS 重写模块，则可禁用运用的 IIS 重写模块。
有关详细信息，请参阅禁用 IIS 模块。

不支持的功能

中间件不支持以下 IIS URL 重写模块功能：

出站规则自定义做事器变量通配符LogRewrittenUrl受支持的做事器变量

中间件支持下列 IIS URL 重写模块做事器变量：

CONTENT_LENGTHCONTENT_TYPEHTTP_ACCEPTHTTP_CONNECTIONHTTP_COOKIEHTTP_HOSTHTTP_REFERERHTTP_URLHTTP_USER_AGENTHTTPSLOCAL_ADDRQUERY_STRINGREMOTE_ADDRREMOTE_PORTREQUEST_FILENAMEREQUEST_URI

备注

也可通过 PhysicalFileProvider 获取 IFileProvider。
这种方法可为重写规则文件的位置供应更大的灵巧性。
请确保将重写规则文件支配到所供应路径的做事器中。

C#复制

PhysicalFileProvider fileProvider = new PhysicalFileProvider(Directory.GetCurrentDirectory());基于方法的规则

利用 Add 在方法中实现自己的规则逻辑。
Add 公开 RewriteContext，这使 HttpContext 可用于方法中。
RewriteContext.Result 决定如何处理其他管道进程。
将值设置为下表中的 RuleResult 字段之一。

基于方法的规则

重写高下文结果

操作

RuleResult.ContinueRules（默认值）

连续运用规则。

RuleResult.EndResponse

停滞运用规则并发送相应。

RuleResult.SkipRemainingRules

停滞运用规则并将高下文发送给下一个中间件。

C#复制

示例运用演示了如何对以 .xml 结尾的路径的要求进行重定向。
如果发出针对 /file.xml 的要求，要求将重定向到 /xmlfiles/file.xml。
状态代码设置为“301 (永久移动)”。
当浏览器发出针对 /xmlfiles/file.xml 的新要求后，静态文件中间件会将文件从 wwwroot / xmlfiles 文件夹供应给客户端。
对付重定向，请显式设置相应的状态代码。
否则，将会返回“200 (正常)”状态代码，且客户端上不会发生重写。

RewriteRules.cs:

C#复制

public static void RedirectXmlFileRequests(RewriteContext context){ var request = context.HttpContext.Request; // Because the client is redirecting back to the same app, stop // processing if the request has already been redirected. if (request.Path.StartsWithSegments(new PathString("/xmlfiles"))) { return; } if (request.Path.Value.EndsWith(".xml", StringComparison.OrdinalIgnoreCase)) { var response = context.HttpContext.Response; response.StatusCode = (int) HttpStatusCode.MovedPermanently; context.Result = RuleResult.EndResponse; response.Headers[HeaderNames.Location] = "/xmlfiles" + request.Path + request.QueryString; }}

此方法还可以重写要求。
示例运用演示了如何重写任何文本文件要求的路径以从 wwwroot 文件夹中供应 file.txt 文本文件。
静态文件中间件基于更新的要求路径来供应文件：

C#复制

RewriteRules.cs:

C#复制

public static void RewriteTextFileRequests(RewriteContext context){ var request = context.HttpContext.Request; if (request.Path.Value.EndsWith(".txt", StringComparison.OrdinalIgnoreCase)) { context.Result = RuleResult.SkipRemainingRules; request.Path = "/file.txt"; }}基于 IRule 的规则

利用 Add 在实现 IRule 接口的类中利用规则逻辑。
与利用基于方法的规则方法比较，IRule 供应了更大的灵巧性。
实现类可能包含布局函数，可在个中传入 ApplyRule 方法的参数。

C#复制

检讨示例运用中 extension 和 newPath 的参数值是否符合多个条件。
extension 须包含一个值，并且该值必须是 .png、.jpg 或 .gif 。
如果 newPath 无效，则会引发 ArgumentException。
如果发出针对 image.png 的要求，要求将重定向到 /png-images/image.png。
如果发出针对 image.png 的要求，要求将重定向到 /jpg-images/image.jpg。
状态代码设置为“301 (永久移动)”，context.Result 设置为停滞处理规则并发送相应。

C#复制

public class RedirectImageRequests : IRule{ private readonly string _extension; private readonly PathString _newPath; public RedirectImageRequests(string extension, string newPath) { if (string.IsNullOrEmpty(extension)) { throw new ArgumentException(nameof(extension)); } if (!Regex.IsMatch(extension, @"^\.(png|jpg|gif)$")) { throw new ArgumentException("Invalid extension", nameof(extension)); } if (!Regex.IsMatch(newPath, @"(/[A-Za-z0-9]+)+?")) { throw new ArgumentException("Invalid path", nameof(newPath)); } _extension = extension; _newPath = new PathString(newPath); } public void ApplyRule(RewriteContext context) { var request = context.HttpContext.Request; // Because we're redirecting back to the same app, stop // processing if the request has already been redirected if (request.Path.StartsWithSegments(new PathString(_newPath))) { return; } if (request.Path.Value.EndsWith(_extension, StringComparison.OrdinalIgnoreCase)) { var response = context.HttpContext.Response; response.StatusCode = (int) HttpStatusCode.MovedPermanently; context.Result = RuleResult.EndResponse; response.Headers[HeaderNames.Location] = _newPath + request.Path + request.QueryString; } }}

原始要求：/image.png

原始要求：/image.jpg