http - 400 和 500 错误页面应该是静态 .html 文件吗？

Question

在构建 Web 应用程序时，错误页面（400、500 状态代码）应该是静态 .html 文件，还是提供动态页面可以，为什么？

我认为如果您的服务器出现故障，您的动态页面也会随之下降。至少对于静态页面，您的负载均衡器可以提供静态文件。

Answer 1

就 HTTP 协议而言，静态页面和动态页面之间没有区别，因此在标准方面，为 400 和 500 提供动态页面没有问题。

但是，正如您所说，如果您的应用程序中有错误，那么尝试提供动态页面可能不是最好的主意，因为它可能会由于相同的错误而失败，甚至如果错误是由于数据库拥塞等

Answer 2

查看您的服务器日志并查看哪些错误发生最多可能会很有趣。通常我发现对于未找到的内容总是有大量的 404。不是因为站点/应用程序中的链接断开，而是因为蜘蛛/垃圾邮件发送者对不存在的页面的随机请求。

动态 404 页面可能会给您的服务器增加额外的负载，但这取决于这些错误的数量以及您的服务器将花费多少时间来动态生成这些错误页面。

如果您有一个动态生成的 404 错误页面，那么我建议您创建一个空白 robots.txt 文件和一个空白/普通 favicon.ico 文件。或者在您的 .htaccess 中删除对至少 favicon 的请求。这样做可以帮助减少 404 的数量，因此具有动态 404 错误页面可能会造成较小的影响。

基本上虽然它没有任何问题 - 从纯粹的性能角度来看，它可能不是最好的主意。这首先取决于您的服务器/应用程序的负载量以及您的服务器有多少净空。

Answer 3

我认为区分 404s 和服务器错误（500s）是有用的。

我想为最终得到 404 的用户提供的一项重要功能是搜索其他内容的能力，这是主应用程序提供的一项功能。当然，您可以在静态页面上重做搜索，但这是多余的。

404 的主要原因是内容已移动或不再存在，在这种情况下，提供搜索是有价值的。并非所有面临 404 的用户都是服务器关闭或应用程序错误的结果。

tl; 博士我会让我的 500 驻留在静态服务器上，并为 404 提供双层，第一个从（动态）应用程序中提供服务，作为故障安全层，另一个 404 路由到我的静态页面服务器。