URL重写2.1.mis

概观

IIS URL重写2.1使Web管理员能够创建强大的规则来实现更容易让用户记住的网址，并使搜索引擎更容易找到。通过使用规则模板，重写映射，.NET提供程序和集成到IIS管理器中的其他功能，Web管理员可以轻松设置规则来定义基于HTTP标头，HTTP响应或请求标头，IIS服务器变量甚至复杂的URL重写行为程序规则。此外，Web管理员可以执行重定向，发送自定义响应，或基于重写规则中表达的逻辑来停止HTTP请求。

定义强大的规则来将复杂的URL转换成简单和一致的Web地址

URL Rewrite允许Web管理员使用.NET编写的重写提供程序，正则表达式模式匹配和通配符映射轻松构建功能强大的规则，以检查URL和其他HTTP标头和IIS服务器变量中的信息。可以编写规则来生成用户可以更容易记住的URL，搜索引擎很容易编制索引，并允许URL遵循一致且规范的主机名格式。URL重写进一步简化了规则创建过程，支持内容重写，规则模板，重写映射，规则验证以及现有mod_rewrite规则的导入。

轻松替换Web应用程序URL以生成用户和搜索引擎友好的结果

URL重写允许Web管理员轻松地将响应HTML中的Web应用程序生成的URL替换为更友好的用户友好的和搜索引擎友好的等价物。可以在逆向代理背后的Web应用程序生成的HTML标记中修改链接。URL重写使出站响应内容和头部重写变得更容易，出站重写规则可以与HTTP请求和响应头以及IIS服务器变量一起工作。

与现有IIS功能无缝集成，可改善管理，性能和故障排除

URL重写与IIS管理器紧密集成以更好地管理。此外，URL Rewrite支持用户模式和内核模式缓存，以提高性能。URL重写还支持失败的请求跟踪，以增强对应用程序逻辑执行的故障排除。

特征

  • 基于规则的URL重写引擎
  • 基于规则的响应重写引擎
  • 支持自定义的.NET重写提供程序
  • 正则表达式模式匹配
  • 通配符模式匹配
  • 全局和分布式重写规则
  • 在特定HTML标记的内容中重写
  • 出站规则的前提条件
  • 访问服务器变量和HTTP头
  • 重写服务器变量和HTTP请求头
  • 重写HTTP响应头
  • 允许列表服务器变量
  • HtmlEncode函数
  • 内置的规则模板
  • 反向代理规则模板
  • 搜索引擎优化的规则模板
  • 各种规则操作，包括重定向和请求中止
  • 在规则条件下跟踪捕获组
  • 记录重写的URL
  • 在IIS管理器中更新了用户界面
  • 用于管理重写规则和重写地图的集成用户界面
  • 用于导入Apache mod_rewrite规则的集成用户界面
  • 用于测试正则表达式和通配符模式的集成用户界面
  • 支持IIS内核模式和用户模式输出缓存
  • 小写转换功能
  • 重写映射以在重写期间生成替换URL
  • 失败的请求追踪支持

奖项

下载URL重写模块2.1

下载可扩展性示例

可扩展性示例为.NET程序集提供了完整的重写提供程序的源代码，这三种最常见的用例是：将重写或重定向映射存储在SQL数据库中; 将重写或重定向映射存储在文本文件中; 将查找子字符串存储在文本文件中。

下载示例

相关学习

用品

论坛

视频

IIS团队刚刚发布了URL Rewrite v2.1。以下博客文章详细介绍了此版本中引入的更改。您可以从https://www.iis.net/downloads/microsoft/url-rewrite或从WebPI 下载最新版本。

控制URL重写规则的响应缓存能力

URL Rewrite v7.1.1909从可缓存的服务器变量集中移除了“HTTP_HOST”。这意味着任何在条件中引用“HTTP_HOST”的URL重写规则或者其操作是重写/重定向并将“HTTP_HOST”设置为其操作的一部分的URL重写规则不再是内核可缓存的。此修复的目的是防止由于缓存导致客户被困在重写循环中，因为URL Rewrite无法检测循环。但是，此更新消除了客户如果知道他们没有任何重定向循环，则允许其响应成为内核可缓存的能力。

引入一个responseCacheDirective

通过
在规则元素responseCacheDirective上引入新的指令，URL重写规则可明确标记为可缓存。

该responseCacheDirective接受四个可能的值：

1. 始终：响应始终可缓存。
2. 从不：响应永远不可缓存
3. NotIfRuleMatched：如果规则匹配，则响应不可缓存。
4. 自动（默认）：URL重写根据规则中使用的服务器变量来确定规则的缓存友好性。

进入重定向循环的风险尚未缓解，因此设置responseCacheDirective来始终只使用时可以验证有没有重定向循环。

当你使用不同的responseCacheDirective定义多个规则时会发生什么？

URL重写会尝试将传入的URL顺序匹配到一组规则。每个规则有三种可能的结果，因为它适用于传入的URL：不匹配，URL匹配和规则匹配，以增加匹配度。匹配的规则与匹配的URL不同，除了匹配的URL之外还满足规则条件。

每个规则都会重新考虑响应的可缓存性，初始状态是一个中性状态，URL重写不会以任何方式指示内核缓存。如果当前状态变为不可缓存，则不考虑进一步的规则来确定缓存能力。换句话说，执行的所有规则中的单个规则足以使整个响应不可缓存。这使得规则的排序很重要在发生“规则匹配”时停止处理的情况。考虑至少有一个规则评估为“URL匹配”，并且该规则被设置为“从不”或“自动”且缓存不友好的服务器的情况。如果这个规则是在规则匹配之前的顺序，那么它会导致内核缓存被禁用。另一方面，如果规则在“规则匹配”规则之后被跳过，则对缓存能力没有影响。

对于一个对缓存能力有影响的规则，规则至少应该是“URL匹配”。如果为给定规则的responseCacheDirective选择了“NotIfRuleMatched” ，则整个规则与URL和条件匹配时，该响应的内核缓存将被禁用。请记住，“NotIfRuleMatched”不考虑缓存不友好的服务器变量。对于“ 永不”和“ 永远”也是如此，只有在存在缓存不友好的服务器变量导致内核缓存被禁用的情况下，Auto才是唯一的值。

保留原始网址编码

在V7.1.1980之前的URL Rewrite版本中，当试图使用UNENCODED_URL时，URL Rewrite将对其进行编码，如果原始URL已经被编码，则可能导致双重编码。这违反了RFC3986的第2.4 节，其中规定“ 实现必须不是百分比 - 不止一次地编码或解码相同的字符串，因为解码已经解码的字符串可能导致错误地解释百分比数据八位组作为百分比编码的开始，反之亦然百分比编码已经百分比的编码 - 编码的字符串“。这也使得UNENCODED_URL的使用变得不切实际，特别是在ARR的反向转发器场景中，后端服务器期望URL不被修改地传递。

在v7.1.1980中，我们添加了一个功能标志useOriginalURLEncoding，允许您在设置为true时关闭此不符合的URL编码。默认行为将保持不变（useOriginalURLEncoding默认为true）。

为了进一步解释这一点，我们来看下面的例子，输入的URL是https://contoso.com/ab%2fde/。在这个例子中，从IIS.SYS接收到的URL 的熟化表示是一旦解码/ ab / de /的URL 。

当保留原始URL编码（useOriginalURLEncoding == true）时，UNENCODED_URL服务器变量通过对传入URL进行编码来计算，这导致双重编码ab％252f。关闭不符合规定的行为（useOriginalURLEncoding = false）后，UNENCODED_URL现在只是传入的URL。

使用URL重写的更常见的方式是后向引用，其中{R：0}表示与规则匹配的URL的整个部分，{R：n}表示与特定部分匹配的URL部分正则表达式用括号括起来。如果RE中有多个部分用括号括起来，n表示RE 中使用的1 <= n <=＃个括号对的顺序。

通过对熟化URL的相应??部分进行编码来计算得到的反向引用。但是，由于我们正在编码熟化的URL，所以不可能确定原始URL中是否存在“ /”  ，或者是第一次解码的人工产物，因此我们不会尝试对其进行编码。在将useOriginalURLEncoding设置为false之后，反向引用现在只是熟化的URL。

原始网址：https：//contoso.com/ab%2fde/

重写规则包含 useOriginalURLEncoding =真 useOriginalEncoding = FALSE
BACK_REFERENCE / AB /德/ / AB /德/
UNENCODED_URL / AB％252fde / / AB％2fde /

我们来看看传入URL已经被双重编码的另一个例子：http：//contoso.com/ab%2520de/。在这个例子中，IIS从HTTP.SYS接收到的* cooked *表示是一次被解码的URL / ab％20de /。

当保留原始URL编码时，UNENCODED_URL服务器变量再次通过对熟化的URL进行编码来计算。关闭不符合规定的行为后，UNENCODED_URL仍然是原始网址。

反向引用是通过对熟化的URL进行编码来计算的。在将useOriginalURLEncoding设置为false之后，URL服务器变量现在就是熟化的 URL。

重写规则包含 useOriginalURLEncoding =真 useOriginalURLEncoding = FALSE
BACK_REFERENCE / AB％2520de / / AB％20de /
UNENCODED_URL / AB％252520de / / AB％2520de /

在这两个示例中，useOriginalURLEncoding = false提供了一种通过使用UNENCODED_URL未修改原始URL的方法。这通常是反向代理场景中的预期结果。它也消除了URL重写模块所执行的任何双重编码。

7评论

  • 很高兴看到IIS团队不睡觉，并在URL重写模块上工作。对于更多新的改进和功能，您可以从UrlRewrite.Net模块获得启发：https：//github.com/Bikeman868/UrlRewrite.Net

    Be3CH -2017年6月30日星期五上午6点03分39秒

  • 我已经通过它实现了ARR访问SAP fiori门户，我已经成功打开页面并登录，但登录后出现“无法加载组”的错误。我已经按照他们打开了SAP的案例。

    原因

    您正在使用第三方代理，如Microsoft IIS，Microsoft UAG，Apache等

    。反向代理在将请求转发到后端之前会自动解码整个URL。‘％2F‘被

    解码为‘/‘。

    解决方案
    配置您的代理服务器以确保它将传递未解码的请求URL。

    注意：我遵循你的指令，升级rewirte 2.0并配置条件{encode_url}模式（。*），但没有正面结果，所以请协助我如何配置代理服务器传递URL未解码。您的及时响应请求

    马利克 -2017年7月10日星期一上午06:35:33

  • 从FailedReqLog文件记录日志：

    ）URL_REWRITE_END重写{0469ABFA-1BB2-466A-B645-E3E15A02F38B} 0 1 4 55 0x0 RPROXY {80000019-0001-FC00-B63F-84710C7967BB} 202.125.137.133 49299 202.125.137.133 443 GENERAL_ENDPOINT_INFORMATION {D42CF7EF-DE92-473E-8B6C-621EA663113A } 0 1 4 50 0x0 RPROXY {80000019-0001-FC00-B63F-84710C7967BB}连接：Keep-Alive接受：application / json Accept-Encoding：gzip，deflate Accept-Language：en Cookie：sap-usercontext = sap-language = EN＆汁液客户= 950; SAP_SESSIONID_GWA_950 = xB0yA-wrScKXERgtrqXQpCqmSUNlPBHnkkYADCmrLiA％3D; 0 false GENERAL_SET_RESPONSE_HEADER {D42CF7EF-DE92-473E-8B6C-621EA663113A} 0 1 5 9 0x800 RPROXY {80000019-0001-FC00-B63F-84710C7967BB} ARR_RESPONSE_ENTITY_START请求路由{53AE50FA-81DF-47B1-8161-71F0A1C55A48} 0 1 5 10 0x800 RPROXY {80000019-0001-FC00-B63F-84710C7967BB} 253 ARR_RESPONSE_ENTITY_END RequestRouting {53AE50FA-81DF-47B1-8161-71F0A1C55A48} 0 1 5 52 0x0 RPROXY {80000019-0001-FC00-B63F-84710C7967BB} 1 GENERAL_NOT_SEND_CUSTOM_ERROR SETSTATUS_SUCCESS {D42CF7EF-DE92- 473E-8B6C-621EA663113A} 0 1 4 35 0x0 RPROXY {80000019-0001-FC00-B63F-84710C7967BB} GENERAL_FLUSH_RESPONSE_START {D42CF7EF-DE92-473E-8B6C-621EA663113A} 0 1 4 47 0x0 RPROXY {80000019-0001-FC00-B63F- 84710C7967BB} Cache-Control：no-cache Pragma：no-cache Content-Length：253 Content-Type：application / json; charset = utf-8过期时间：}} GENERAL_RESPONSE_ENTITY_BUFFER {D42CF7EF-DE92-473E-8B6C-621EA663113A} 0 1 4 36 0x0 RPROXY {80000019-0001-FC00-B63F-84710C7967BB} 580 0 GENERAL_FLUSH_RESPONSE_END操作成功完成。（0x0）{D42CF7EF-DE92-473E-8B6C-621EA663113A} 0 1 0 2 0x0 RPROXY {80000019-0001-FC00-B63F-84710C7967BB} 580 1100 200 0 GENERAL_REQUEST_END {D42CF7EF-DE92-473E-8B6C-621EA663113A}

    马利克 -2017年7月10日星期一6:46:34 AM

  • 当我们将在URLrewrite中启用递归搜索？例如，我想规则，从孩子的web.config和根web.config执行只是引用指向孩子的web.config ..

时间： 2024-11-08 04:57:25

URL重写2.1.mis的相关文章

Cento7+Nginx 之 URL重写

Cento7+Nginx  之  URL重写 我们前一篇文章写了一个Cento7+Nginx 反向代理实现多域名跳转,今天主要介绍一下Cento7+Nginx  之  URL重写, Hostname:A-S.IXMSOFT.COM IP:192.168.5.20 Role:Nginx server 我们首先准备安装Nginx仓库 Yum install http://nginx.org/packages/centos/7/noarch/RPMS/nginx-release-centos-7-0.

二:理解ASP.NET的运行机制(例:基于HttpHandler的URL重写)

url重写就是把一些类似article.aspx?id=28的路径重写成 article/28/这样的路径 当用户访问article/28/的时候我们通过asp.net把这个请求重定向到article.aspx?id=28路径有两种方法可以做这件事情 一:基于HttpModule的方案这个方案有有缺点,具体缺点以后再谈我曾写过一篇文章<不用组件的url重写(适用于较大型项目) >就是按这个模式写的 二:基于HttpHandler的方案我们这个例子就是按这个方案做的我们接下来就按这种方式做这个例

Url Rewrite 再说Url 重写

前几天看到园子里一篇关于 Url 重写的文章<获取ISAPI_Rewrite重写后的URL>, URL-Rewrite 这项技术早已不是一项新技术了,这个话题也已经被很多人讨论过多次.搜索一下URL-Rewrite可以找到很多URL-Rewrite方面的文章和组件,自己以前也多次接触过这个东东,也来说说吧. ScottGu 有一篇非常经典的 URL-Rewrite Blog Tip/Trick: Url Rewriting with ASP.NET http://weblogs.asp.net

LNMP的搭建及URL重写测试

内容: 1.LNMP的搭建 2.搭建基于LNMP的discuz论坛(www.hill.com) 3.实现https 4.实现访问http时自动跳转至https以及防盗链设置.URL重写测试 一.LNMP的搭建 我们知道,在apache与php的结合方式有三种,而nginx与php的结合目前只有一种是行之有效的:php-fpm 1.yum直接安装快速搭建LNMP,官方下载nginx的预安装包(rpm包),当然也可以编译安装 #yum install -y prce-devel zlib-devel

Nginx反向代理、负载均衡、页面缓存、URL重写及读写分离详解

大纲 一.前言 二.环境准备 三.安装与配置Nginx 四.Nginx之反向代理 五.Nginx之负载均衡 六.Nginx之页面缓存 七.Nginx之URL重写 八.Nginx之读写分离 注,操作系统为 CentOS 6.4 x86_64 , Nginx 是版本是最新版的1.4.2,所以实验用到的软件请点击这里下载:http://yunpan.cn/QXIgqMmVmuZrm 一.前言 在前面的几篇博文中我们主要讲解了Nginx作为Web服务器知识点,主要的知识点有nginx的理论详解.ngin

Cookie / Session / URL重写

Cookie //创建一个Cookie对象 Cookie cookie = new Cookie("username","JACK"); //在客户端存储的时间(生命周期)单位是秒 7天 7*24*60*60 //如果这里设置为0 就表示客户端不保存该cookie 即临时cookie //如果设置为-1 就表示客户端关闭之后就删除该cookie 也可以称之为临时cookie cookie.setMaxAge(-1); //设置cookie在客户端存放的路径 如果不设

Session，Cookie，jsessionid，Url重写

在一些投票之类的场合,我们往往因为公平的原则要求每人只能投一票,在一些WEB开发中也有类似的情况,这时候我们通常会使用COOKIE来实现,例如如下的代码: < % cookie[]cookies = request.getCookies(); if (cookies.lenght == 0 || cookies == null){ doStuffForNewbie(); //没有访问过 }else{ doStuffForReturnVisitor(); //已经访问过了 } % > 这是很浅显

URL重写技术总结

概要:什么是url重写? URL 重写是截取传入 Web 请求并自动将请求重定向到其他 URL 的过程.比如浏览器发来请求 hostname/101.html ,服务器自动将这个请求中定向为http://hostname/list.aspx ?id=101. url重写的优点在于: 1.缩短url,隐藏实际路径提高安全性. 2.易于用户记忆和键入. 3.易于被搜索引擎收录. 正文:实现url重写的基本方法: 一. 下载ms的URLRewriter.dll,放到你的web程序的bin下 下载地址1

ASP.NET 中执行 URL 重写

具体实现步骤(其中的一种实现方法): 一.下载相关的DLL(ActionlessForm.dll和UrlRewriter.dll) http://download.csdn.net/detail/yingwanghbx/4510059 二.在项目中引用那两个DLL文件 右击项目,点击Add Reference,选择Browse,然后选择相应的DLL,点击OK即可. 三.添加browser文件 1.右击项目,点击Add-New Item,选择Browser File,取个有意义的名字.在生成的*.