ステータスコード500に追加のオーバーヘッドはありますか？
クエリ文字列に特定の情報を必要とするこれらのWebアプリケーションがあります。その情報が提供されない場合、アプリケーションはエラーをスローします。クエリ文字列のないURLは既存のページを指していないため、404で明示的に処理する必要があるように思えます。
ほとんどの経営者は私と意見が違うようです。彼らが主張します：
正しいqsを含めずにページにリンクするようなものではありません。そのため、最終的に500ページになるのは、意図的に、または壊れたコピーペーストのためにそこに行った人だけです。
200と404で見られる以上に500に追加のオーバーヘッドはありませんか？もしそうなら、攻撃者はエラーをスローするURLに集中することでDoSをトリガーするのが簡単になりませんか？
（この場合、Oracle Weblogicを使用していますが、一般的なケースに興味があります。）
私は両方の方法で有効な引数を見ることができます。一方、 HTTP/1.1標準、セクション6 は、次のような4xxおよび5xxステータスコードを定義します。
4xx：クライアントエラー-リクエストに不正な構文が含まれているか、リクエストを実行できません
5xx：サーバーエラー-サーバーは明らかに有効な要求を実行できませんでした
この場合、「クエリ文字列内の特定の情報」のないURLは「明らかに有効なリクエスト」ではなく、そのような不正なリクエストはアプリケーションによって実行されることはありません。したがって、正式には、これはクライアントエラーであり、応答は4xxステータスコード（たとえば 400 Bad Request 、または 404 Not Found ）である必要があります。
一方、実用的な観点からは、 500 Internal Server Error 応答を返さないほうが都合が良い場合は、本当の理由はありません。ええ、アプリが基本的にURLが有効であると主張しているのに少し馬鹿げていますが、それは常に処理に失敗しますが、HTTP応答コードはコンピューター向けであり、コンピューターは「愚かな」ことを気にしません。
実際には、400と500の応答の唯一の違いは、一部の検索エンジンが何らかの理由でこのような無効なURLに遭遇した場合、might500回の応答よりも400回の応答の後にリクエストを再試行する方が少し熱心になります。しかし、それでもかなり限界的なユースケースです。
どちらかを選択する理由がない場合は、セマンティックの正確さのために400応答を使用する必要がありますが、アプリが既に500応答を生成している場合、実際に変更する必要はありません。 「追加のオーバーヘッド」はありません-それは単なる数字です。
もちろん、アプリとウェブサーバーで何が起こるかinsideについて明確に言うことはできません。可能性は低いものの、Webサーバーが500の応答を見るたびに非常に面倒なことを行う可能性があります。その場合、実際にそれらを回避する必要があります。多少可能性が高いのは、アプリがエラーに遭遇する前に不正なリクエストを処理するのに時間を浪費する可能性があることです。その場合、そのようなリクエストを早期に検出することで実際に時間を節約できます（ただし、それぞれにわずかな余分な時間がかかりますvalidリクエスト）。いずれにせよ、アプリが有効なリクエストよりも無効なリクエストの処理に多くの時間を費やすことはないと思われるため、有効なリクエストを生成するのが多少困難な場合を除き、DoS攻撃の可能性があるユーザーがあなたにスパムを送信する可能性がありますvalidリクエストを代わりに。
500ステータスコードに余分なオーバーヘッドはありません。適切な引数が与えられていれば、アプリケーションはそのURLでクエリを受け入れることができるため、管理は正しいと主張します。
DoS攻撃に対抗するために500エラーではなく404エラーを返すことは、実際のところ、あいまいさによるセキュリティへのアピールにすぎません。