mod_rewrite NE 标志 - 什么时候对 URL 中的特殊字符进行编码有帮助？

Question

我一直在查看 mod_rewrite 中的 [NE] (noescape) 标志。经过一番思考，我无法弄清楚什么情况下我不想想要使用该标志。这意味着，在几乎每个 RewriteRule 中保持启用该标志似乎最有帮助。在某些情况下，不调用此标志给我带来了问题。

我处理的大多数规则都是 HTTP 重定向 ([R])，而不是传递。

有人会透露一下什么时候让 mod_rewrite 对 URL 进行编码有帮助吗？

启用此标志通常是一种好的做法，还是使用允许 mod_rewrite 转义这些特殊字符的默认行为？为什么？

Answer 1

如果您查看 mod_rewrite 的源代码，您会注意到，如果启用了 noescape，它会设置一个 proxy-nocanon 标志。

在修订版中该行首次添加的位置，还包含以下注释：

确保 mod_proxy_http 不会规范化 URI，并在 mod_proxy_http:proxy_http_canon() 的文件名中保留任何（可能是 qsappend'd）查询字符串

接下来，如果您阅读 mod_proxy 文档，您将看到以下提及 nocanon 的内容：

通常情况下，mod_proxy 会将 ProxyPassed URL 规范化。但这可能与某些后端不兼容，特别是那些使用 PATH_INFO 的后端。可选的 nocanon 关键字可以抑制这种情况，并将 URL 路径“raw”传递到后端。请注意，这可能会影响后端的安全性，因为它消除了代理提供的针对基于 URL 的攻击的正常有限保护。

我可能是错的，但这对我来说意味着在 mod_proxy 中使用 nocanon （以及在 mod_rewrite 中扩展 noescape）具有潜在的安全影响。这可以解释为什么它默认被禁用，即使在大多数情况下启用它似乎更有用。

Answer 2

当您将请求 URL 添加为授权签名的一部分时，[NE] 标志非常有用。

我刚刚遇到一个错误，授权在 .htaccess 关闭时有效，但在 .htaccess 打开时无效。事实证明，原因是重定向对最终出现在 php $_GET 参数中的项目进行了 url 编码。为了解决这个bug，我将：

RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*[^/0-9])$ $1/ [R=301,L]

改为

RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*[^/0-9])$ $1/ [NE,R=301,L]

（授权签名由很多东西组成，其中之一就是请求url）