http - 为什么 http ://google. com/a/bogus/url 不重定向到 404 URL，为什么这是首选？

Question

1. 转到 http://google.com/a/bogus/url
2. 您将看到一个 404 页面(HTTP 代码为 404)
3. 但是浏览器中的 url 仍然是 http://google.com/a/bogus/url

为什么？

为什么这种行为优于重定向到单个 404 页面 URL，例如 http://google.com/pagenotfound 或类似的东西？

背景

我首先在我们实现的 Drupal 站点中注意到这种行为。如果您访问一个不存在的页面，即:http://mysite.com/a/bogus/url/，它会显示“找不到页面”消息。如果您使用 TELNET 获取页面，您会看到返回了正确的 HTTP 404 错误代码，但 URL 没有被重写。我对此感到震惊，所以我在 Drupal.org 上打开了一个错误报告。在写错误报告时，我想用谷歌作为(我认为)应该发生的事情的例子。令我沮丧的是，谷歌也在做同样的事情!

你为什么关心？你大概会问。好吧，假设我在我的网站上安装了 Google Analytics。如果 404 页面 URL 按照我的预期被重写，那么我应该能够运行报告并查看我的访问者看到我的唯一 404 页面的次数。然后我可以看到他们来自哪里，并希望找到有问题的链接。

就目前而言，Google Analytics 脚本将从 http://mysite.com/a/bogus/url/ 执行，并且会很高兴地报告有人刚刚看到了这个页面。那我怎么知道有人看过 404 页面呢？我并不是真的在寻找我的特定编程问题的答案，而是想深入了解为什么重定向不是一种常见的做法。

如有任何想法，我们将不胜感激。

Answer 1

将重定向返回到带有错误消息的页面是不正确的。您告诉客户该页面确实存在，位于不同的地址，然后又告诉他们它根本不存在。或者，更糟糕的是，通常情况下，您的错误页面会以 200 OK 响应的形式返回，因此您声称页面不存在时确实存在。

这会减慢浏览器的速度，迫使它们发出额外的完全不必要的请求，并且会混淆自动化工具。这也意味着如果您随后将文件放在地址 a/bogus/url 中，用户将无法点击重新加载来获取它，因为他们最终会到达一个地址只会显示错误。这也可能对缓存不利，因为重定向响应可能是可缓存的。

虽然 404 的情况并不像将所有服务器端错误 (500) 重定向到单独的错误页面地址的同样常见的错误那么糟糕。

使用重定向而不是仅仅返回不同的页面作为响应通常是服务器端脚本语言的产物，它将传入的 URL 绑定(bind)到 View ，例如 .asp(*)。 Google 没有使用要求他们指定将在 URL 中返回的 View 的框架，因此他们不需要发出重定向。他们可以以更有效和正确的方式做到这一点。

(*:尽管即使在 ASP[.NET] 中，您也可以通过 Server.Transfer 推送到不同的页面，而无需发出重定向。不幸的是，这在 ASP 编码人员中并不常见；有一种文化偏好——我会称它为重定向的一种疾病，通常最终会导致可怕的重定向循环和调试问题。)

How then am I supposed to know when someone has seen a 404 page?

任何体面的网络日志分析器都允许您根据 HTTP 响应进行搜索。事实上，您会通过这种方式获得更好、更准确的结果，并且在每种情况下都会为您提供完全错误的链接，而重定向不会发生这种情况。

why redirection is not a common practice.

是一种常见的做法。这是一种常见的错误做法，需要避免。