NGINX删除删除扩展名为.html
于是,我找到了答案,以消除我的网页,与此代码工作正常,在.html扩展名:NGINX删除删除扩展名为.html
server {
listen 80;
server_name _;
root /var/www/html/;
index index.html;
if (!-f "${request_filename}index.html") {
rewrite ^/(.*)/$ /$1 permanent;
}
if ($request_uri ~* "/index.html") {
rewrite (?i)^(.*)index\.html$ $1 permanent;
}
if ($request_uri ~* ".html") {
rewrite (?i)^(.*)/(.*)\.html $1/$2 permanent;
}
location/{
try_files $uri.html $uri $uri/ /index.html;
}
}
但是,如果我打开mypage.com它重定向我mypage.com/index
这不是通过将index.html声明为索引来解决的吗?任何帮助表示赞赏。
更新回答:这个问题引起了我的好奇心,于是我继续深入搜索了一个针对.html
在Nginx中重定向的“圣杯”解决方案。这里是我找到的答案的链接,因为我自己没有拿出它:https://*.com/a/32966347/4175718
但是,我将举一个例子并解释它是如何工作的。下面是代码:
location/{
if ($request_uri ~ ^/(.*)\.html$) {
return 302 /$1;
}
try_files $uri $uri.html $uri/ =404;
}
这里发生的事情是一个非常巧妙地利用了if
指令。 Nginx在传入请求的$request_uri
部分运行正则表达式。正则表达式检查URI是否具有.html扩展名,然后将URI的无扩展部分存储在内置变量$1
中。
从docs,因为我花了一段时间才能找出其中$1
来自何处:
正则表达式可以包含在$ 1 .. $ 9个变量可供以后重用捕获。
正则表达式既检查是否存在不需要的.html请求,也有效地清理了URI以便它不包含扩展名。然后,使用简单的return
语句将请求重定向到现在存储在$1
中的已清理的URI。
这个最好的部分,作为原作者cnst解释说,是
由于事实,即$ REQUEST_URI始终是每个请求不变,而不受其他重写,它不会,事实上,形成任何无限循环。
不像重写,其上操作任何.html
请求(包括不可见的内部重定向到/index.html
),该解决方案仅操作于对用户可见的外部的URI。
您仍然需要try_files
指令,否则Nginx将不知道如何处理新清理的无扩展URI。该try_files
指令可以作为这样的:
的Nginx会首先追加
.html
到URI的结尾,并尝试为它服务。如果它找到合适的.html
文件,它将返回该文件并保留无扩展名的URI。如果找不到合适的.html
文件,它将尝试没有任何扩展名的URI,然后将URI作为目录,最后返回404错误。
注意,这被认为是if
指令的安全使用,每Nginx的页面。如果是邪恶的:
唯一的100%安全的事情,可以在一个位置内,如果完成背景是:
return ...;
重写...最后;
这也经常出现在我身上,并且由于工作时的配置,位置块最好并且/ & .php块被锁定。这意味着大多数解决方案都不适合我。
所以这里是我从上面的接受答案简化的一个。
rewrite ^/(.*)\.html /$1/ permanent;
为的CMS,其中底层框架产生
我相信我用rewrite方法遇到的问题是/index.html会被重定向到/ index。这会导致无限循环,或导致登录页面变为www.example.com/index。 – Arnon
页面的伟大工程你怎么使用302重定向,而不是301? – WillB
@WillB由于301重定向是由浏览器缓存的,我喜欢使用302,除非我100%确定我永远不想撤消重定向。从我看到的情况来看,Google似乎并不太在意,如果有一天您决定要回到URL中的.html扩展名中,它会变得更容易。 – Arnon
try_files语句应该在if块之外... – goliatone