![使用 Azure Web App/Linux 进行重写而不是重定向](https://linux22.com/image/764850/%E4%BD%BF%E7%94%A8%20Azure%20Web%20App%2FLinux%20%E8%BF%9B%E8%A1%8C%E9%87%8D%E5%86%99%E8%80%8C%E4%B8%8D%E6%98%AF%E9%87%8D%E5%AE%9A%E5%90%91.png)
我正在尝试使用 Linux+Apache(+PHP)在 Azure Web 应用上配置重写规则.htaccess
,但是我只能使重定向起作用(但不能重写)。
源代码结构如下:
./.htaccess
./updates/
./updates/.htaccess
./updates/check/
./updates/check/api.php
./updates/certificates/
./updates/certificates/api.php
./... # other files - must not be downloadable
我的./.htaccess
是:
order deny,allow
deny from all
RewriteEngine on
RewriteRule "^updates/([A-Za-z]+)" "/updates/$1/api.php" [L,QSA]
编辑:问题仍然存在
RewriteRule "^updates/([A-Za-z]+)$" "/updates/$1/api.php" [L,QSA]
我的./updates/.htaccess
是:
order allow,deny
allow from all
我需要的是进行内部重写,将其重写/updates/check?foo=bar
为/updates/check/api.php?foo=bar
和。/updates/certificates?a=b&c=d
/updates/certificates/api.php?a=b&c=d
我得到的是 HTTP 301 重定向到http://$server/updates/check/?foo=bar
。当我将R=301
(或R=302
) 添加到规则标志时,我得到了 301 (或 302) 重定向到http://$server/updates/check/api.php?foo=bar
。请注意http
两种情况下的 (我使用 curl 向 https 发出请求)和第一种情况下完全错误的重写。
我不确定客户端是否可以处理重定向。这就是我尝试进行内部重写的原因。
我要做什么才能使重写工作正常?
答案1
我得到的是 HTTP 301 重定向到
http://$server/updates/check/?foo=bar
是的,因为check
是物理子目录,所以 mod_dir 将(默认情况下)通过 301 外部重定向在 URL 路径后附加一个尾部斜杠来“修复”URL。这对于 mod_dir 提供服务DirectoryIndex
(如果您有)是必要的。
如果您将 URL 更改为包含尾随斜杠,则不会遇到此问题。
您可以通过禁用DirectorySlash
。如果您这样做,必须确保目录索引(mod_autoindex)被禁用,以防止意外泄露您的文件系统。
例如,在根文件的顶部.htaccess
:
Options -Indexes
DirectorySlash Off
这也意味着,如果不使用内部重写(或外部重定向)手动添加尾随斜杠,则无法直接访问任何其他目录 - 尽管这对您来说可能是也可能不是问题。
参考:
更新:由于这个“限制”,我倾向于改变文件(或 URL)结构来避免此类冲突,而不是禁用DirectorySlash
。
例如:
/updates/check-api.php
/updates/certificates-api.php
并相应重写:
RewriteRule ^updates/([A-Za-z]+)$ /updates/$1-api.php [L]
在旁边:
order deny,allow deny from all
请注意,这些是 Apache 2.2 指令,在 Apache 2.4 中已弃用。您应该改用Require all denied
和Require all granted
。但是,您应该避免混合使用旧/新 auth 指令,因为您可能会得到意想不到的结果(一个指令不一定会覆盖另一个指令)。