为什么http://google.com/a/bogus/url 不重定向到404 URL，为什么首选此选项？ 去 您将看到一个404页面（HTTP代码为404） 但浏览器中的url仍为http://google.com/a/bogus/url 为什么？

为什么这种行为比重定向到单个404页面URL（如

http://google.com/pagenotfound

还是类似的

背景 我首先在我们实现的Drupal站点中注意到这种行为。如果您访问一个不存在的页面，即：

http://mysite.com/a/bogus/url/

它显示一条“未找到页面”消息。如果使用TELNET获取页面，您会看到返回了正确的HTTP404错误代码，但URL没有被重写。我被它震惊了，所以我在Drupal.org上打开了一个bug报告。在写bug报告的时候，我想用谷歌作为一个例子，说明（我认为）应该发生什么。令我沮丧的是，谷歌也做了同样的事情

你为什么在乎？你大概会问。好吧，假设我的网站上安装了Google Analytics。如果404页面的URL像我期望的那样被重写，那么我应该能够运行一个报告，看看我的访问者看到我的404页面的次数。然后我可以看到他们来自哪里，并希望找到令人不快的联系

目前，Google Analytics脚本将从

http://mysite.com/a/bogus/url/

并且会很高兴地报告有人刚刚看到了此页面。那我怎么知道有人看到了404页面？我并不是在寻找我特定编程问题的答案，而是要深入了解重定向为何不是一种常见做法

任何想法都将不胜感激

为什么这种行为比重定向到一个404页面的URL更受欢迎

可能有人打错了。如果能知道/看看情况是否如此，那就太好了

此外：

如果404页面的URL像我期望的那样被重写，那么我应该能够运行一个报告，看看我的访问者看到我的404页面的次数

---

Web服务器日志中的

404

不是吗？

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

这会减慢浏览器的速度，迫使它们发出一个完全不必要的额外请求，并会混淆自动化工具。这还意味着，如果您随后将文件放在地址

a/bogus/url

，用户将无法点击“重新加载”按钮获取该文件，因为他们最终的地址只会显示错误。这也会影响缓存，因为重定向响应可能是可缓存的

虽然404s的情况并不像将所有服务器端错误（500）重定向到一个单独的错误页面地址那样糟糕

使用重定向而不是仅仅返回不同的页面作为响应通常是服务器端脚本语言的产物，这些语言将传入的URL绑定到视图，如.asp（*）。谷歌没有使用一个要求他们指定在URL中返回什么视图的框架，因此他们不需要发出重定向。他们可以用更有效、更正确的方法来做

（*：虽然即使在ASP[.NET]中，您也可以使用服务器.Transfer来推送到不同的页面，而无需发出重定向。不幸的是，在ASP程序员中，这不是一种常见的做法；有一种文化偏好——我将其称为重定向疾病，这通常会导致可怕的重定向循环和调试灾难。）

那我怎么知道有人看到了404页面

任何合适的web日志分析器都允许您基于HTTP响应进行搜索。事实上，通过这种方式，您将得到更好、更准确的结果，并且在每种情况下，您都会得到确切的错误链接，这在重定向中是不会发生的

为什么重定向不是一种常见的做法

---

这是一种常见的做法。这是一种常见的错误做法，应该避免。

我会考虑重定向404到另一页是不寻常的行为。听起来Drupal和Google做了正确的事情。同意，但想知道原因是：-]谢谢你的输入！看起来好像没有重定向，但在虚假URL中出现404错误才是正确的选择。非常感谢！PeeHaa，如上所述，谷歌的做法似乎是可取的。谢谢