今天360搜索引擎例行的网站安全检查，网站后台记录下了这一过程：

这里面我发现一些记录从后台无法打开的，例如这条：//chixintf.com/'))%20AND%202733=3566%16

原因很简单：这些是以制表符(tab)结尾的URL。这些URL是使用函数 htmlspecialchars() 处理过的,将里面的单引号和双引号使用 % 加两位16进制数字替换了，访问这些URL时，IIS会返回400 bad request的错误：

整个问题界面是由IIS的框架http.sys直观重返的，既不是自表述问题界面，也并不是展开URL重写。我呢？们要的但是是网站访问是这样的URL时，能手动调用至合适的URL（祛除结局的造表符）。

既而想借着IIS URL Rewrite Module来保证 ，但今天表单提交一直被http.sys在社会底层屏蔽了，完全顺利到达不聊URL Rewrite Module。挺好，可能经由注册成功表安装让http.sys不屏蔽这样的的URL。

注册网站表设定工艺如下图所示：

regedit打开注册网站表剪辑器，进到HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters

增长键值：AllowRestrictedChars REG_DWORD 1 （默许为0，会阻止\x00-\x1F与\x7F-\x9F的字符串，造表符的ASCII码是\x09）

强制关机http.sys与IIS，使注册会员表的设定终止：

• net stop http
  

• net start http

• iisreset

怎样制定后续，URL中分为制作表格符的要求就能赶到IIS URL Rewrite Module，然而用一条什么URL重写细则去重专向自动转跳。结杲却知道基本不易用途，没去自动转跳，照样是400不正确的，只的现阶段是由ASP.NET返回了的。

HTTP Error 400.0 - Bad Request

ASP.NET detected invalid characters in the URL.

这基本上是URL Rewrite Module的一些小bug。

随后适用了一大个折衷的完成方案，不去重定位跳出，只去URL重写，其实尽管说URL对不上，但只要新页面应该很正常互访。

然而然后选用了那么的URL重写细则折衷地缓解了故障：

<rule name="endwith_tab" stopProcessing="true">

    <match url="^([^.]+\.(?:html|php))[\x09]" />

    <conditions logicalGrouping="MatchAll" trackAllCaptures="false" />
      <action type="Rewrite" url="{R:1}" appendQueryString="false" />

</rule>

番外篇：介绍htmlspecialchars变量的使用方法

这位方式方法比效简略，通道的场所也许多 ，首要数据能够 查到一会儿php工作手册，这里的英文我给同学们贴出他的使用的一定值：

    $str = "Bill & 'Steve'";
    echo htmlspecialchars($str, ENT_COMPAT); // 只转换双引号echo "<br>";
    echo htmlspecialchars($str, ENT_QUOTES); // 转换双引号和单引号echo "<br>";
    echo htmlspecialchars($str, ENT_NOQUOTES); // 不转换任何引号