使用HTTP標頭重定向到其他頁面/文檔還是合並動態消息來通知用戶拒絕訪問，是更好的選擇嗎？

Question

我想知道通知用戶拒絕其訪問嘗試的最佳實踐是什么。 我意識到可能還有更多選擇，但是這些是我正在考慮的方法：

我想知道優缺點。 目前，我可以提出以下建議：

Answer 1

我強烈建議您不要重定向，原因很簡單，因為原始URL不再可編輯。

如果我在網址中輸入錯誤：

http://example.com/users/jwheared

並重定向到：

http://example.com/denied

現在，更正我的錯字對我來說比較麻煩：

http://example.com/users/jwheare

同樣的原則適用於404或任何其他錯誤頁面。 同樣，如果這是服務器臨時錯誤，則重定向到其他URL會刪除稍等片刻，然后稍后刷新頁面的功能。

除了以用戶為中心的建議外，錯誤頁面還應提供相關的HTTP錯誤代碼（如其他答案所述，可能是401未經授權）。

最佳實踐是遵循HTTP規范，並且3xx重定向狀態代碼均不適用於您描述的情況。

編輯：另一個重要的一點是，這可能會損害您的搜索引擎性能。 如果搜尋器訪問了未經授權的頁面並收到重定向，它將將您所有的未經授權的頁面視為一個頁面，並有可能提高錯誤頁面的排名。 如果您發送正確的錯誤標頭，則搜尋器更有可能正確地將該URL標識為未授權，而忽略它。

Web搜尋器通常是笨拙的客戶端，僅實現HTTP規范的最低要求。 考慮他們以及使用網絡瀏覽器的人們是值得的。

Answer 2

重定向到當前請求中的錯誤頁面或錯誤控制器/操作（如果使用的是MVC結構）。

還要確保您發送正確的HTTP標頭（代碼401是拒絕訪問的正確標頭），以便搜索機器人或類似工具了解正在發生的情況。

1.重定向專家：可能會更加混淆？

混淆的目的是什么？

2. Pro for request頁面中的消息：HTTP服務器上的請求更少？

您提供的內容幾乎不會訪問所有拒絕訪問拒絕頁面的內容。 所以我真的不認為這是決定一個或另一個的理由。 並不是說用戶會在無法訪問的網站上遭受F5打擊。

編輯：總結：並沒有真正的區別，但是如果您可以嘗試不重定向並確保發送正確的標頭。

EDIT2：正如James Wheare在評論中指出的那樣，將HTTP重定向到錯誤頁面是違反HTTP規范的。 換句話說：不要重定向，而是將錯誤和正確的標題一起直接打印在錯誤發生的頁面上。

Answer 3

不要使用重定向。 最好與錯誤文檔一起發送適當的狀態碼（例如406）。

Answer 4

嘗試失敗的密碼失敗百分比是多少，輸入密碼錯誤的百分比是多少？ 如果主要是前者，是的，如果您認為這樣做會給他們帶來更多不便，請將它們重定向到一個單獨的HTTP頁面。

另一方面，如果只在同一頁面上放置一條消息，則可以使合法客戶更容易輸入正確的密碼。