NGINX删除.html扩展名 [英] NGINX remove .html extension

问题描述

因此，我找到了删除页面上的.html扩展名的答案，该扩展名可以与以下代码配合使用:

So, I found an answer to removing the .html extension on my page, that works fine with this code:

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声明为index可以解决此问题吗?感谢您的帮助.

But if I open mypage.com it redirects me to mypage.com/index
Wouldn't this be fixed by declaring index.html as index? Any help is appreciated.

推荐答案

在NGINX中删除".html"的圣杯"解决方案:

更新后的答案:这个问题激起了我的好奇心，然后我又进行了一次更深入的搜索，以寻找Nginx中.html重定向的圣杯"解决方案.这是我找到的答案的链接，因为我自己没有提出答案: https://stackoverflow.com/a /32966347/4175718

The "Holy Grail" Solution for Removing ".html" in NGINX:

UPDATED ANSWER: This question piqued my curiosity, and I went on another, more in-depth search for a "holy grail" solution for .html redirects in Nginx. Here is the link to the answer I found, since I didn't come up with it myself: https://stackoverflow.com/a/32966347/4175718

但是，我将举一个示例并说明其工作方式.这是代码:

However, I'll give an example and explain how it works. Here is the code:

location / {
    if ($request_uri ~ ^/(.*)\.html$) {
        return 302 /$1;
    }
    try_files $uri $uri.html $uri/ =404;
}

这里发生的是if指令的巧妙用法. Nginx在传入请求的$request_uri部分上运行一个正则表达式.正则表达式检查URI是否具有.html扩展名，然后将URI的无扩展名部分存储在内置变量$1中.

What's happening here is a pretty ingenious use of the if directive. Nginx runs a regex on the $request_uri portion of incoming requests. The regex checks if the URI has an .html extension and then stores the extension-less portion of the URI in the built-in variable $1.

从 docs 开始，因为花了我一段时间才弄清楚$1来自:

From the docs, since it took me a while to figure out where the $1 came from:

正则表达式可以包含捕获，供以后在$ 1 .. $ 9变量中重用.

Regular expressions can contain captures that are made available for later reuse in the $1..$9 variables.

regex会检查是否存在不需要的.html请求，并有效地清理URI，使其不包含扩展名.然后，使用简单的return语句，将请求重定向到现在存储在$1中的经过清理的URI.

The regex both checks for the existence of unwanted .html requests and effectively sanitizes the URI so that it does not include the extension. Then, using a simple return statement, the request is redirected to the sanitized URI that is now stored in $1.

正如原始作者 cnst 所解释的，关于这一点的最好的部分是

The best part about this, as original author cnst explains, is that

由于$ request_uri对于每个请求始终是恒定的，并且不受其他重写的影响，因此它实际上不会形成任何无限循环.

Due to the fact that $request_uri is always constant per request, and is not affected by other rewrites, it won't, in fact, form any infinite loops.

与对任何 .html请求(包括对/index.html的不可见内部重定向)进行的重写不同，此解决方案仅对用户可见的外部URI起作用.

Unlike the rewrites, which operate on any .html request (including the invisible internal redirect to /index.html), this solution only operates on external URIs that are visible to the user.

您仍然需要try_files指令，否则Nginx将不知道如何处理新清理的无扩展名URI.上面显示的try_files指令将首先单独尝试新的URL，然后使用扩展名".html"尝试，然后将其作为目录名称尝试.

You will still need the try_files directive, as otherwise Nginx will have no idea what to do with the newly sanitized extension-less URIs. The try_files directive shown above will first try the new URL by itself, then try it with the ".html" extension, then try it as a directory name.

Nginx文档还解释了默认try_files指令的工作方式.默认的try_files指令的顺序与上面的示例不同，因此下面的说明并不完美:

The Nginx docs also explain how the default try_files directive works. The default try_files directive is ordered differently than the example above so the explanation below does not perfectly line up:

Nginx首先将.html附加到URI的末尾并尝试提供它.如果找到合适的.html文件，它将返回该文件并保留无扩展名的URI .如果找不到合适的.html文件，它将尝试不带任何扩展名的URI，然后将URI作为目录，最后返回404错误.

Nginx will first append .html to the end of the URI and try to serve it. If it finds an appropriate .html file, it will return that file and will maintain the extension-less URI. If it cannot find an appropriate .html file, it will try the URI without any extension, then the URI as a directory, and then finally return a 404 error.

更新:正则表达式做什么?

上面的答案涉及到正则表达式的使用，但是对于仍然好奇的人，这是更具体的解释.使用以下正则表达式(regex):

UPDATE: What does the regex do?

The above answer touches on the use of regular expressions, but here is a more specific explanation for those who are still curious. The following regular expression (regex) is used:

^/(.*)\.html$

其分解为:

^:表示行首.

/:从字面上匹配字符"/".在Nginx中不需要转义正斜杠.

/: match the character "/" literally. Forward slashes do NOT need to be escaped in Nginx.

(.*):捕获组:无限匹配任意字符

(.*): capturing group: match any character an unlimited number of times

\.:匹配字符."字面上地.必须使用反斜杠将其转义.

\.: match the character "." literally. This must be escaped with a backslash.

html:从字面上匹配字符串"html".

html: match the string "html" literally.

$:表示行尾.

捕获组(.*)是包含URL的非".html"部分的内容.以后可以用变量$1引用它.然后将Nginx配置为重试请求(return 302 /$1;)，并且try_files指令在内部重新添加".html"扩展名，以便可以定位文件.

The capturing group (.*) is what contains the non-".html" portion of the URL. This can later be referenced with the variable $1. Nginx is then configured to re-try the request (return 302 /$1;) and the try_files directive internally re-appends the ".html" extension so the file can be located.

要保留传递给.html页的查询字符串和参数，可以将return语句更改为:

To retain query strings and arguments passed to a .html page, the return statement can be changed to:

return 302 /$1?$args;

这应该允许诸如/index.html?test的请求重定向到/index?test而不是仅仅重定向到/index.

This should allow requests such as /index.html?test to redirect to /index?test instead of just /index.

从Nginx页面看是否邪恶:

From the Nginx page If Is Evil:

如果在位置上下文中，可以在内部完成的唯一100％安全的事情是:

The only 100% safe things which may be done inside if in a location context are:

返回...;

重写...最后;

---

另外，请注意，您可以将"302"重定向换成"301".

301重定向是永久性的，并由Web浏览器和搜索引擎缓存.如果您的目标是从搜索引擎已经索引的页面中永久删除.html扩展名，则需要使用301重定向.但是，如果要在实时站点上进行测试，则最佳做法是从302开始，仅在完全确定配置正确运行时才移至301.

---

Also, note that you may swap out the '302' redirect for a '301'.

A 301 redirect is permanent, and is cached by web browsers and search engines. If your goal is to permanently remove the .html extension from pages that are already indexed by a search engine, you will want to use a 301 redirect. However, if you are testing on a live site, it is best practice to start with a 302 and only move to a 301 when you are absolutely confident your configuration is working correctly.

这篇关于NGINX删除.html扩展名的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！