调试 .htaccess 重写规则的技巧 [英] Tips for debugging .htaccess rewrite rules

问题描述

许多发布者在调试 .htaccess 文件中的 RewriteRule 和 RewriteCond 语句时遇到问题.其中大多数使用共享托管服务，因此无法访问根服务器配置.他们无法避免使用 .htaccess 文件进行重写，并且无法启用 RewriteLogLevel".正如许多受访者所建议的那样.此外，还有许多 .htaccess 特定的陷阱和约束没有很好地涵盖.设置本地测试 LAMP 堆栈对大多数人来说涉及太多的学习曲线.

Many posters have problems debugging their RewriteRule and RewriteCond statements within their .htaccess files. Most of these are using a shared hosting service and therefore don't have access to the root server configuration. They cannot avoid using .htaccess files for rewriting and cannot enable a RewriteLogLevel" as many respondents suggest. Also there are many .htaccess-specific pitfalls and constraints are aren't covered well. Setting up a local test LAMP stack involves too much of a learning curve for most.

所以我的问题是我们如何建议他们调试他们的规则他们自己.我在下面提供一些建议.其他建议将不胜感激.

So my Q here is how would we recommend that they debug their rules themselves. I provide a few suggestions below. Other suggestions would be appreciated.

1. 了解 mod_rewrite 引擎循环遍历 .htaccess 文件.引擎运行这个循环:

1. Understand that the mod_rewrite engine cycles through .htaccess files. The engine runs this loop:

do
  execute server and vhost rewrites (in the Apache Virtual Host Config)
  find the lowest "Per Dir" .htaccess file on the file path with rewrites enabled
  if found(.htaccess)
     execute .htaccess rewrites (in the user's directory)
while rewrite occurred

因此您的规则将被重复执行，如果您更改 URI 路径，那么它可能最终会执行其他 .htaccess 文件(如果它们存在).所以确保你终止这个循环，如有必要，通过添加额外的 RewriteCond 来停止规则触发.同时删除任何较低级别的 .htaccess 重写规则集，除非明确打算使用多级规则集.

So your rules will get executed repeatedly and if you change the URI path then it may end up executing other .htaccessfiles if they exist. So make sure that you terminate this loop, if necessary by adding extra RewriteCond to stop rules firing. Also delete any lower level .htaccess rewrite rulesets unless explicitly intent to use multi-level rulesets.

通过针对一组测试模式进行测试来确保每个 Regexp 的语法是正确的，以确保这是一个有效的语法，并通过全面的测试达到您的预期URI.有关详细信息，请参阅下面的答案.

Make sure that the syntax of each Regexp is correct by testing against a set of test patterns to make sure that is a valid syntax and does what you intend with a fully range of test URIs. See answer below for more details.

在测试目录中逐步构建您的规则.您可以使用执行路径功能上最深的 .htaccess 文件"设置一个单独的测试目录(树)并在此处调试规则集，而不会弄乱您的主要规则并停止您的站点工作.您必须一次添加一个，因为这是将故障定位到单个规则的唯一方法.

Build up your rules incrementally in a test directory. You can make use of the "execute the deepest .htaccess file on the path feature" to set up a separate test directory (tree) and debug rulesets here without screwing up your main rules and stopping your site working. You have to add them one at a time because this is the only way to localise failures to individual rules.

使用虚拟脚本存根转储服务器和环境变量.(参见清单 2)如果您的应用程序使用，例如，blog/index.php，那么您可以将其复制到 test/blog/index.php> 并使用它来测试 test 子目录中的博客规则.您还可以使用环境变量来确保重写引擎正确解释替换字符串，例如

Use a dummy script stub to dump out server and environment variables. (See Listing 2)If your app uses, say, blog/index.php then you can copy this into test/blog/index.php and use it to test out your blog rules in the test subdirectory. You can also use environment variables to make sure that the rewrite engine in interpreting substitution strings correctly, e.g.

RewriteRule ^(.*) - [E=TEST0:%{DOCUMENT_ROOT}/blog/html_cache/$1.html]

并在 phpinfo 转储中查找这些 REDIRECT_* 变量.顺便说一句，我使用了这个并在我的网站上发现我不得不使用 %{ENV:DOCUMENT_ROOT_REAL} 代替.在重定向器循环的情况下，REDIRECT_REDIRECT_* 变量会列出之前的传递.等等.

and look for these REDIRECT_* variables in the phpinfo dump. BTW, I used this one and discovered on my site that I had to use %{ENV:DOCUMENT_ROOT_REAL} instead. In the case of redirector looping REDIRECT_REDIRECT_* variables list the previous pass. Etc..

确保您不会被浏览器缓存不正确的 301 重定向所困扰.请参阅下面的答案.感谢 Ulrich Palha.

重写引擎似乎对 .htaccess 上下文中的级联规则很敏感，(这就是 RewriteRule 导致替换的地方，这虽然进一步规则)，因为我发现了内部子请求的错误 (1) 和不正确的 PATH_INFO 处理，这通常可以通过使用 [NS]、[L] 和 [PT] 标志来防止.

The rewrite engine seems sensitive to cascaded rules within an .htaccess context, (that is where a RewriteRule results in a substitution and this falls though to further rules), as I found bugs with internal sub-requests (1), and incorrect PATH_INFO processing which can often be prevents by use of the [NS], [L] and [PT] flags.

还有什么意见或建议吗?

Any more comment or suggestions?

<?php phpinfo(INFO_ENVIRONMENT|INFO_VARIABLES);

推荐答案

这里有一些关于测试规则的额外提示，可以简化共享主机用户的调试

Here are a few additional tips on testing rules that may ease the debugging for users on shared hosting

在测试新规则时，添加一个条件以仅使用用于请求的 fake 用户代理来执行它.这样就不会影响您网站上的其他任何人.

When testing a new rule, add a condition to only execute it with a fake user-agent that you will use for your requests. This way it will not affect anyone else on your site.

例如

#protect with a fake user agent
RewriteCond %{HTTP_USER_AGENT}  ^my-fake-user-agent$
#Here is the actual rule I am testing
RewriteCond %{HTTP_HOST} !^www.domain.com$ [NC] 
RewriteRule ^ http://www.domain.com%{REQUEST_URI} [L,R=302] 

如果您使用的是 Firefox，您可以使用 用户Agent Switcher 创建假用户代理字符串并进行测试.

If you are using Firefox, you can use the User Agent Switcher to create the fake user agent string and test.

我看过很多帖子，人们仍在测试他们的规则并且他们正在使用 301.不要.

I have seen so many posts where people are still testing their rules and they are using 301's. DON'T.

如果您没有在您的网站上使用建议 1，那么不仅您自己，而且当时访问您网站的任何人都会受到 301 的影响.

If you are not using suggestion 1 on your site, not only you, but anyone visiting your site at the time will be affected by the 301.

请记住，它们是永久性的，并且会被您的浏览器主动缓存.使用 302 代替，直到您确定，然后将其更改为 301.

Remember that they are permanent, and aggressively cached by your browser. Use a 302 instead till you are sure, then change it to a 301.

如果您的规则不起作用并且看起来正确，并且您没有使用建议 1 和 2，请在清除浏览器缓存后或在无痕浏览时重新测试.

If your rule does not work and it looks right to you, and you were not using suggestions 1 and 2, then re-test after clearing your browser cache or while in private browsing.

使用诸如 Fiddler 之类的 HTTP 捕获工具来查看浏览器和服务器之间的实际 HTTP 流量.

Use a HTTP capture tool like Fiddler to see the actual HTTP traffic between your browser and the server.

虽然其他人可能会说您的站点看起来不正确，但您可以查看并报告所有图像、css 和 js 都返回 404 错误，很快缩小问题范围.

While others might say that your site does not look right, you could instead see and report that all of the images, css and js are returning 404 errors, quickly narrowing down the problem.

虽然其他人会报告您从 URL A 开始并在 URL C 结束，但您将能够看到他们从 URL A 开始，被 302 重定向到 URL B 和 301重定向到 URL C.即使 URL C 是最终目标，您也会知道这对 SEO 不利，需要修复.

While others will report that you started at URL A and ended at URL C, you will be able to see that they started at URL A, were 302 redirected to URL B and 301 redirected to URL C. Even if URL C was the ultimate goal, you will know that this is bad for SEO and needs to be fixed.

您将能够看到在服务器端设置的缓存标头、重放请求、修改请求标头以进行测试......

You will be able to see cache headers that were set on the server side, replay requests, modify request headers to test ....

这篇关于调试 .htaccess 重写规则的技巧的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！