出于某种原因,这条规则
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ ./rewrite.php?p=$1&%{QUERY_STRING} [L]
不适用于此类http://site.com/index/var/val的网址 所有其他URL工作,但事实并非如此。当我删除时它开始工作!-f 部分或重命名index.php文件位于根目录中的其他东西(例如test.php)。那么在mod_rewrite眼中,site.com/index似乎等于site.com/index.php?这些文件位于根目录中,因此不应包含任何其他(上部).htaccess文件。这不会发生在索引中,例如,如果我创建/something.xml,test.com/something / ...将突然停止工作。这仅在某些服务器上发生。
有谁知道为什么会发生这种情况?
PS。 / index目录在此服务器上不存在
答案 0 :(得分:4)
故障模块是mod_negotiation,而不是mod_rewrite。
在debian中:
a2dismod negotiation
修改强>
更具体一点,这是由mode_negotiation处理的多视图的效果。因此,您可以使用以下命令保留模块并删除MultiViews处理:
Options -MultiViews
来自文档:
MultiViews选项启用了MultiViews搜索。如果服务器收到/ some / dir / foo的请求并且/ some / dir / foo不存在,那么服务器会读取名为foo。*的所有文件的目录,并有效地伪造一个类型映射,该映射将所有这些命名为如果客户端通过名称请求其中一个文件,则为它们分配相同的媒体类型和内容编码。然后它选择与客户要求的最佳匹配,并返回该文档。
答案 1 :(得分:0)
我也通过从
中删除MultiViews关键字来解决这个问题<Directory>
我的服务器配置部分。
希望这有帮助。
我相信${REQUEST_FILENAME}
会将文件视为直接提供给浏览器。
我遇到了类似的问题:
/content/detailed-page
(重写的URL并由php解析)该文件以与以下相同的方式返回给我:
/content/detailed-page.html
(真实档案)