キャンセルされたリクエストの正しいHTTPステータスコードとは
TCP接続がHTTPリクエストの作成中にクライアントによってキャンセルされた場合、サーバーでの作業を停止し、空の応答を返します。戻りますか？
一貫性を保つために、400 Bad Requestこれで、バックエンドアプリがクライアントの切断を識別できる場合、または接続を拒否または閉じる場合、おそらくNginxの非標準コード499または444を返すことができます。
499 Client Closed Requestサーバーが応答を送信する前にクライアントが要求を閉じたときに使用されます。
444 No Responseサーバーがクライアントに情報を返さず、接続を閉じたことを示すために使用されます。
HTTP（1.0/1.1）には、リクエストをキャンセルする手段がありません。応答が不要になった場合にクライアントができることは、接続を閉じて、配信できなくなった応答の処理を停止するための最適化がサーバーに含まれていることです。接続が閉じられたため、クライアントには応答もステータスコードも実際には配信できません。そのため、「返す」コードはご自身の満足のためだけのものです。私は個人的に4xxの範囲で何かを選びます1 「障害」-応答を送信できなくなった理由-はクライアントによるものです。
HTTP 2.0では、エンドポイントがEND_STREAMまたはRST_STREAMを発行して、接続全体を切断せずに1つのストリームに関心がなくなったことを示すことができます。ただし、それらはそのストリームで送信されたHEADERSまたはDATAを無視することを意図しているため、理論的にステータスコードを配信しても、クライアントはそれを完全に無視します。
1完全に適切と思われるより具体的なエラーを特定できないため、おそらく400自体です。
もっともらしい選択肢がいくつかあります（もちろん、500を除く）。
202承認済み
処理が完了していないため、完了しません。
これは、アプリケーションドメインで、元の要求者がすべての要求が満たされるわけではないことを「期待する」場合にのみ適切です。
409紛争
…リクエストの作成とキャンセルの間。
これは弱く正当化されているだけです。キャンセルはまだ発生していないため、状況によっては、1つのクライアントが期限切れの情報に基づいてリクエストを行うことはありません。
503サービス利用不可
このサービスは、実際にはこの1つのリクエストでは利用できません（キャンセルされたためです！）。
"エラーをエラーとして報告する" の一般的な引数は、409または503を優先します。したがって、503はデフォルトです。
本当にすることはほとんどありません。 RFC 7230、セクション6.5 からの引用：
クライアント、サーバー、またはプロキシは、いつでもトランスポート接続を閉じることができます。
これは、HTTPレベルではなく、TCPレベルで発生しています。接続の処理を停止するだけです。不完全/破損したリクエストの意図は単なる推測であるため、ステータスコードはここではほとんど意味を与えません。また、クライアントに転送する手段はありません。