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.

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

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 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. 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. 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. 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] 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.. Make sure that you don't get bitten by your browser caching incorrect 301 redirects. See answer below. My thanks to Ulrich Palha for this. 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.

还有什么评论或建议吗?

清单1——phpinfo

<?php phpinfo(INFO_ENVIRONMENT|INFO_VARIABLES);

当前回答

最好的调试方法!

在apache的httpd.conf文件中增加LogLevel notice rewrite:trace8,记录所有mod_rewrite的通知。如果你在共享主机上,无法访问httpd.conf,那么就在本地测试并上传到现场。一旦启用这将在很短的时间内生成一个非常大的日志,这意味着它不能在活跃的服务器上进行测试。

其他回答

如果你正在使用url,你可能想要检查是否“启用Mod重写”

也许调试重写规则的最好方法是根本不使用重写规则,而是将URL处理从htaccess文件推迟到PHP文件(让我们称之为router.php)。然后,您可以使用PHP进行任何您喜欢的操作,并使用适当的错误检测和常规的调试方法。这甚至运行得更快,因为您不必使用重写模块。

对于文件系统中没有的URL,要立即将控制权从.htaccess转移到router.php,只需在.htaccess中放入以下一行:

FallbackResource router.php

是的,真的很简单。是的,它确实有效。试一试。

注意:你可能需要在你的。htaccess文件中使用一个ErrorDocument指令来在HTTP状态404时显式地将某些url的控制权传递给你的router.php文件,特别是如果你继承了处理状态404的父htaccess文件。这样一来,将控制权传递到路由器文件总共需要两行。

一个是我浪费的几个小时:

如果你已经应用了所有这些技巧,但因为你没有访问服务器错误日志而只出现了500个错误,也许问题不在.htaccess文件中,而在它重定向到的文件中。

在我修复了我的.htaccess问题之后,我又花了两个多小时试图修复它,即使我只是忘记了一些权限。

下面是一些关于测试规则的额外技巧,可以简化共享主机上用户的调试

1. 使用伪用户代理

在测试一个新规则时,添加一个条件,以只使用一个伪用户代理执行它,您将在请求中使用这个假用户代理。这样就不会影响到你网站上的其他人。

e.g

#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,您可以使用用户代理切换器来创建假用户代理字符串并进行测试。

2. 在测试完成之前不要使用301

我见过很多帖子,人们仍然在测试他们的规则,他们使用的是301。不喜欢。

如果你没有在你的网站上使用建议1,那么不仅是你,而且当时访问你网站的任何人都将受到301的影响。

请记住,它们是永久的,并被浏览器积极缓存。 在确定之前,先用302,然后再换成301。

3.请记住,301缓存在您的浏览器中

如果您的规则不起作用,并且看起来对您来说是正确的,并且您没有使用建议1和2,那么在清除浏览器缓存后或在私人浏览时重新测试。

4. 使用HTTP捕获工具

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

虽然其他人可能会说您的网站看起来不正确,但您可以看到并报告所有的图像、css和js都返回404错误,从而迅速缩小问题范围。

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

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


如果你不是在一个标准的共享主机环境中工作,而是在一个你有管理权限的环境中工作(可能是你的本地测试环境),确保启用了.htaccess和mod_rewrite。它们在默认Apache安装中被禁用。在这种情况下,在.htaccess文件中配置的任何操作都不起作用,即使正则表达式完全有效。

启用。htaccess:

找到apache2.conf文件,在Debian/Ubuntu的/etc/apache2中,在文件中的section

<Directory /var/www/>
    Options Indexes FollowSymLinks
    AllowOverride None
    Require all granted
</Directory>

并更改行AllowOverride None为AllowOverride All。

启用mod_rewrite模块:

在Debian/Ubuntu上执行

sudo a2enmod rewrite

顺便说一下,要禁用一个模块,你可以使用a2dismode而不是a2enmode。

完成上述配置更改后,重新启动Apache使其生效:

sudo systemctl restart apache2