http - 400 と 500 のエラー ページは静的な .html ファイルにする必要がありますか?

Question

Web アプリケーションを構築する場合、エラー ページ (400、500 ステータス コード) は静的な .html ファイルにする必要がありますか、それとも動的なページを提供しても問題ありませんか? また、その理由は?

サーバーがダウンすると、動的ページもダウンすると思います。少なくとも静的ページでは、ロード バランサーは静的ファイルを提供できます。

Answer 1

HTTPプロトコルに関する限り、静的ページと動的ページの間に違いはありません。したがって、標準的には、400と500の動的ページを提供することに問題はありません。

ただし、あなたが言うように、アプリケーションにエラーがある場合、動的ページを提供しようとすることは、同じエラーが原因で失敗する可能性があるため、おそらく最善のアイデアではありません。エラーが原因である場合は、問題を悪化させることさえあります。データベースの混雑などに。

Answer 2

サーバーログを調べて、どのエラーが最も発生するかを確認するのは興味深いかもしれません。通常、見つからないコンテンツには常に404がたくさんあります。サイト/アプリケーション内のリンク切れが原因ではなく、スパイダー/スパマーが存在しないページに対するランダムなリクエストが原因です。

動的な404ページはサーバーに余分な負荷を加える可能性がありますが、サーバーがこれらのエラーページを動的に生成するために費やす時間については、それらのエラーの量によって異なります。

動的に生成された404エラーページがある場合は、空白のrobots.txtファイルと空白/プレーンなfavicon.icoファイルを作成することをお勧めします。または、.htaccessに少なくともファビコンのリクエストをドロップします。そうすることで404の数を減らすことができるので、動的な404エラーページがあると影響が少なくなる可能性があります。

基本的には問題はありませんが、純粋なパフォーマンスの観点からは最善のアイデアではない可能性があります。それは、サーバー/アプリケーションが実際にどの程度ロードされているか、およびサーバーにどれだけのヘッドルームがあるかによって異なります。

Answer 3

404 とサーバー エラー (500) の区別が役立つと思います。

最終的に 404 になるユーザーに提供したい重要な機能の 1 つは、他のコンテンツを検索する機能です。これは、メイン アプリによって提供される機能です。確かに静的ページで検索をやり直すことはできますが、それは冗長です。

404 の主な原因は、コンテンツが移動したか、存在しなくなったことです。この場合、検索を提供することが重要です。404 に直面しているすべてのユーザーが、サーバーのダウンまたはアプリケーション エラーの結果であるとは限りません。

tl;dr 500 を静的サーバーに常駐させ、(動的) アプリ内から最初に提供される 404 用のデュアル レイヤーを提供し、フェイルセーフ レイヤーとして、静的なページへの別の 404 ルートを提供します。サーバ。