直接服務404

Question

所以我有一個Nginx服務器設置，它應該使用4個服務器塊將所有http重定向到https（以及非www到www）。

的問題是，任何404或不存在的HTTP URL首先得到301重定向到如果假設存在什麼可能是一個HTTPS版本（因此創建一個額外的URL和重定向）。

參見例如：

1）http://example.com/thisurldoesntexit

301重定向

2）https://example.com/thisurldoesntexit

3）https://example.com/notfound

有沒有辦法將用戶直接重定向到https 404（URL 3）？

Answer 1

使用https://www.drupal.org/project/fast_404模塊直接爲404頁面提供服務，沒有太多過載。

Answer 2

我建議重定向到一個404頁是一個糟糕的選擇，你應該改爲投放404上不正確的URL。

我對這個聲明的原因是：

• 通過重定向離開該頁面，你正在發行的標頭隱說「的內容沒有在此URL存在，但在這裏做了。」我不知道各種搜索引擎將如何被重定向到反應的404
• ，當我說有關於我的URL變化時，我已經被打錯，我可以從我自己的經驗爲用戶說話單個角色可能非常令人沮喪。然後我需要花時間重新輸入整個URL。
• 可避免在您的.htaccess文件或任何邏輯來判斷一個網頁的404這將大大簡化您最初的邏輯（其由這通過計算得到的每一個頁面加載） - 以及將遠遠刪除更多重定向比http://badurl到https://badurl到https://404

Answer 3

首先，如已經指出，這樣做，從一個不存在的頁面301重定向到一個/notfound綽號僅僅是一個奇數，是一個非常不好的做法，並且很可能違背RFC。

• 如果用戶只是輸入了一個長URL的單個字符會怎麼樣？現代瀏覽器使其返回到已輸入的內容以修正它是不平凡的。用戶必須決定您的網站是否值得重新打樣，或者您的競爭對手是否想過更好的體驗。

• 如果什麼用戶只需跟着斷開的鏈接，這是一個非常明顯的方式打破了，可以很容易解決嗎？例如，http://www.example.org/www.example.com/page，其中創建者將絕對URL錯誤地指定爲相對地址，或者可能是URI（如/page.html.），並在最後加上一個額外的點。同樣，你會完全混淆用戶與正在發生的事情，並提供糟糕的用戶體驗，如果單獨留下，URL很容易被及時更正。

但是，更重要的是，什麼真正的問題是，你實際上是試圖解決？

• 是好還是壞，這是一個相當普遍的做法不加選擇地重定向從http到https方案，沒有一個帳戶是否給定的頁面可能會或可能不存在。事實上，如果你使用HSTS，那麼通過http服務的內容實際上變得毫無意義;帶有策略的瀏覽器甚至不會請求任何超過http的內容。

• 毫無疑問，要知道給定頁面是否存在，您必須諮詢後端。因此，您不妨在後端內執行從http到https的重定向;但它很可能會佔用您寶貴的服務器資源，而不會帶來額外的好處。

• 此外，頁面的存在或不存在可能由cookie的內容決定。因此，如果您需要您的後端必須辨別http請求是否存在頁面，那麼您將首先泄露私有信息，這些私人信息本來應該受到https的保護。 （反過來，如果你的網站有沒有這樣的私人信息，那麼也許你不應該擺在首位使用https。）

因此，總體而言，整個方法是隻是一個非常，非常糟糕的主意！

考慮，而不是：

• 做不做301所有不存在的網頁，以一個單一的/notfound頁面重定向。非常糟糕的做法，非常糟糕的UX。

• 這是完全OK做不加區別重定向從http到https，不考慮是否存在該頁面。事實上，這不僅是好的，而且是神的意圖，因爲對手不應該能夠辨別是否存在基於https的網站的給定網頁，因此，如果您找到並實施了針對您的解決方案的解決方案「問題」，那麼你將有效地創建一個安全漏洞和一個數據泄漏。