Hướng dẫn nginx remove html - nginx loại bỏ html

Giải pháp "Chén Thánh" để loại bỏ ".html" trong nginx:

Câu trả lời cập nhật: Câu hỏi này đã khơi gợi sự tò mò của tôi và tôi đã tiếp tục tìm kiếm sâu hơn, sâu sắc hơn cho một giải pháp "Chén Thánh" cho .html chuyển hướng trong Nginx. Đây là liên kết đến câu trả lời tôi tìm thấy, vì tôi đã không tự mình nghĩ ra: https://stackoverflow.com/a/32966347/4175718 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

Tuy nhiên, tôi sẽ đưa ra một ví dụ và giải thích cách nó hoạt động. Đây là mã:

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

Những gì đang xảy ra ở đây là một cách sử dụng khá khéo léo của Chỉ thị if. Nginx chạy một regex trên phần $request_uri của các yêu cầu đến. Regex kiểm tra xem URI có phần mở rộng .html và sau đó lưu trữ phần không mở rộng của URI trong biến tích hợp $1.

Từ các tài liệu, vì tôi phải mất một thời gian để tìm ra $1 đến từ đâu:

Biểu thức thông thường có thể chứa các bản ghi được cung cấp để sử dụng lại sau này trong các biến $ 1 .. $ 9.

Cả Regex đều kiểm tra sự tồn tại của các yêu cầu .html không mong muốn và vệ sinh hiệu quả URI để nó không bao gồm phần mở rộng. Sau đó, bằng cách sử dụng một câu lệnh return đơn giản, yêu cầu được chuyển hướng đến URI được vệ sinh hiện được lưu trữ trong $1.

Phần hay nhất về điều này, như tác giả ban đầu CNST giải thích, đó là

Do thực tế là $ request_uri luôn không đổi cho mỗi yêu cầu và không bị ảnh hưởng bởi các bản viết lại khác, trên thực tế, nó sẽ không tạo thành bất kỳ vòng lặp vô hạn nào.

Không giống như các bản viết lại, hoạt động theo bất kỳ yêu cầu .html nào (bao gồm cả chuyển hướng nội bộ vô hình sang

^/(.*)\.html

1), giải pháp này chỉ hoạt động trên URI bên ngoài có thể nhìn thấy cho người dùng.any .html request (including the invisible internal redirect to

^/(.*)\.html

1), this solution only operates on external URIs that are visible to the user.

"Try_Files" làm gì?

Bạn vẫn sẽ cần chỉ thị

^/(.*)\.html

2, vì nếu không Nginx sẽ không biết phải làm gì với các URI không có mở rộng mới được vệ sinh. Chỉ thị

^/(.*)\.html

2 được hiển thị ở trên trước tiên sẽ tự thử URL mới, sau đó thử nó với tiện ích mở rộng ".html", sau đó thử nó dưới dạng tên thư mục.

Các tài liệu nginx cũng giải thích cách chỉ thị

^/(.*)\.html

2 mặc định hoạt động. Chỉ thị mặc định

^/(.*)\.html

2 được đặt hàng khác với ví dụ trên nên lời giải thích dưới đây không hoàn toàn xếp hàng:

Nginx trước tiên sẽ nối lại .html vào cuối URI và cố gắng phục vụ nó. Nếu nó tìm thấy một tệp .html thích hợp, nó sẽ trả về tệp đó và sẽ duy trì URI không mở rộng. Nếu nó không thể tìm thấy một tệp .html thích hợp, nó sẽ thử URI mà không cần bất kỳ tiện ích mở rộng nào, thì URI là thư mục, và cuối cùng trả về lỗi 404.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.

Cập nhật: Regex làm gì?

Câu trả lời trên chạm vào việc sử dụng các biểu thức thường xuyên, nhưng đây là một lời giải thích cụ thể hơn cho những người vẫn còn tò mò. Biểu thức chính quy sau (Regex) được sử dụng:

^/(.*)\.html

Điều này bị phá vỡ như:

^/(.*)\.html

9: Cho biết bắt đầu dòng.

return 302 /$1$is_args$args;

0: Kết hợp nhân vật "/" theo nghĩa đen. Tiếng chém về phía trước không cần phải thoát ra trong Nginx.

return 302 /$1$is_args$args;

1: Nhóm bắt giữ: Kết hợp bất kỳ ký tự nào một số lần không giới hạn

return 302 /$1$is_args$args;

2: Kết hợp nhân vật "." theo đúng nghĩa đen. Điều này phải được trốn thoát với một dấu gạch chéo ngược.

return 302 /$1$is_args$args;

3: Kết hợp chuỗi "HTML" theo nghĩa đen.

Nhóm chụp

return 302 /$1$is_args$args;

1 là phần chứa phần không-". HTML" của URL. Điều này sau này có thể được tham chiếu với biến $1. Nginx sau đó được cấu hình để thử lại yêu cầu (

return 302 /$1$is_args$args;

6) và Chỉ thị

^/(.*)\.html

2 Đưa lại phần mở rộng ".html" để tệp có thể được định vị.

Cập nhật: Giữ lại chuỗi truy vấn

Để giữ lại các chuỗi truy vấn và các đối số được chuyển đến trang .html, câu lệnh return có thể được thay đổi thành:

return 302 /$1$is_args$args;

Điều này sẽ cho phép các yêu cầu như .html0 chuyển hướng đến .html1 thay vì chỉ .html2.

---

Lưu ý rằng đây được coi là cách sử dụng an toàn của chỉ thị `if`.

Từ trang nginx nếu là xấu xa:

Những điều duy nhất an toàn 100% có thể được thực hiện bên trong nếu trong bối cảnh vị trí là:

trở về ...;

Viết lại ... cuối cùng;

---

Ngoài ra, lưu ý rằng bạn có thể trao đổi '302' chuyển hướng cho '301'.

Chuyển hướng .html3 là vĩnh viễn và được lưu trữ bởi các trình duyệt web và công cụ tìm kiếm. Nếu mục tiêu của bạn là xóa vĩnh viễn tiện ích mở rộng .html khỏi các trang đã được công cụ tìm kiếm lập chỉ mục, bạn sẽ muốn sử dụng chuyển hướng .html3. Tuy nhiên, nếu bạn đang thử nghiệm trên một trang web trực tiếp, tốt nhất là bắt đầu với .html6 và chỉ chuyển sang .html3 khi bạn hoàn toàn tự tin cấu hình của mình hoạt động chính xác.