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

Question

转到http://google.com/a/bogus/url

• You的

1. 将看到一个404页(HTTP是404)
2. ，但是浏览器中的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作为一个例子来说明(我认为)应该发生什么。令我沮丧的是，谷歌也做了同样的事情！

你为什么这么在意？你大概会问。嗯，假设我在我的网站上安装了。如果404页URL是按照我的预期重写的，那么我应该能够运行一个报告，看看我的访问者看了多少次我的页面，也只有404页。然后，我可以看到他们从哪里来，并希望找到冒犯的联系。

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

任何想法都将不胜感激。

Answer 1

使用错误消息将重定向返回到页是不正确的。您告诉客户端页面确实存在，地址不同，然后告诉他们它根本不存在。或者，更糟糕的是，通常情况下，错误页面作为200 OK响应返回，因此您声称页面在不存在时确实存在。

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

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

使用重定向而不是仅仅返回一个不同的页面作为响应，通常是服务器端脚本语言将传入的URL绑定到视图的伪制品，比如.asp(*)。Google并没有使用一个框架来要求他们指定在URL中返回什么视图，所以他们不需要发出重定向。他们可以用更有效、更正确的方式来做这件事。

(*：即使在ASP.NET中，您也可以在不发出重定向的情况下将Server.Transfer推送到另一个页面。不幸的是，在ASP程序员中，这种做法并不常见；有一种文化偏好--我称之为疾病--用于重定向，结果往往会导致可怕的重定向循环和调试问题。

，那么，当有人看到404页时，我怎么会知道呢？

任何体面的web日志分析器都将允许您基于HTTP响应进行搜索。事实上，这样你会得到更好、更准确的结果，并且在每一种情况下你都会得到精确的不正确的链接，这在重定向过程中不会发生。

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

这是一种常见的做法。这是一种常见的错误做法，必须避免。

Answer 2

为什么这种行为比重定向到单个404页面URL (如http://google.com/pagenotfound之类的)更可取？

可能有人做错了。很高兴知道/看看是否是这样的。

另外：

--如果404页面URL按我预期的那样被重写了，那么我应该能够运行一个报告，看看我的访问者看了多少次我的页面--也只有404页。

404不是在网络服务器的日志中吗？