HTTPサーバーが「Connection：keep-alive」ヘッダーを含むHTTP / 1.0リクエストを受け取った場合、クライアントが「Transfer-Encoding：chunked」を理解するのは当然のことですか？
基本的に、HTTP / 1.0クライアントからの「Connection：keep-alive」ヘッダーを尊重するかどうかを決定しようとしています。私がそれを尊重する場合、Content-Lengthヘッダーを計算するために応答全体をバッファリングできないため、応答にチャンクコーディングを使用する必要があります。
「Connection：keep-alive」を要求するHTTP / 1.0クライアントがチャンクコーディングも理解することを期待するのが安全でない場合は、応答するたびに接続を閉じる必要があります。（または私は何かを逃したことがありますか？）
これは決定的な「いいえ」です。仕様からの引用：
ただし、HTTP / 1.0クライアントとの持続的接続では、チャンク転送コーディングを利用できないため、各メッセージの終了境界をマークするためにContent-Lengthを使用する必要があります。
HTTP 1.0では、チャンク転送エンコーディングはできません。チャンク転送エンコーディングを使用したKeep-aliveリクエストは、実際にはHTTP1.0と1.1の明確な違いの1つです。
サーバーが、キープアライブやチャンク転送エンコーディングなど、すべてのクライアントがサポートしているわけではない機能を使用できるようにするには、応答を開始する前に、クライアントがその機能と互換性があることを知っておく必要があります。最初のリクエスト後のクライアントとサーバー間の双方向通信。
クライアントはリクエストにKeep-Aliveヘッダーを含めることができるため、 Keep-alive自体をHTTP 1.0でサポートできます。これは、クライアントがKeep-Aliveヘッダーをサポートしていることをサーバーに示します。
HTTP 1.0クライアントがチャンク転送エンコーディングをサポートしていることを示す確立された方法がないため、サーバーがチャンク応答をHTTP1.0要求に送信することはできません。チャンクされた応答をそれを理解していないクライアントに送信すると、クライアントはガベージを受け取ります。
HTTP 1.0がkeep-aliveを使用する場合、チャンク転送エンコーディングなしで使用します。
keep-aliveがチャンク転送エンコーディングを使用できない場合、応答ごとにContent-Lengthヘッダーを送信する必要があります。つまり、有効なContent-Lengthヘッダーを生成するために、サーバーが応答の開始時に応答のコンテンツの長さを知っている場合にのみ、HTTP1.0でキープアライブが可能になります。これは、応答がスクリプトによって生成され、サーバーが送信前にその全体をバッファリングしない場合には当てはまらない可能性があります。
サーバーが応答の送信を開始する前に応答の内容の長さを知らない場合、サーバーは単にその応答のキープアライブを無効にします。サーバーが可能な場合、すべての応答を維持応答にすることは必須ではありません。
HTTP 1.1クライアントは、キープアライブとチャンク転送エンコーディングの両方をサポートする必要があるため、HTTP 1.1要求を行う場合、クライアントはプロトコルとしてHTTP / 1.1を指定するだけで、キープアライブヘッダーを指定しません。
実際には、クライアントはキープアライブヘッダーを送信する可能性があるため、サーバーがHTTP1.0のみをサポートしている場合でもキープアライブを使用できます。サーバーがHTTP1.1以降をサポートしている場合、そのヘッダーは無視され、HTTP/1.1プロトコルインジケーターが優先されます。注：今日のサーバーがHTTP 1.1以降をサポートしないことは非常にまれであると思いますが、それでもキープアライブをサポートするため、それを送信してもほとんど役に立ちません。
Transfer-EncodingはHTTP1.1のみにあることを考えると、絶対にそうではありません。Connection: keep-aliveあなたの状況を考えると、HTTP 1.0クライアントのヘッダーを実際にサポートできるとは思いません（あなたのユースケースでは、それ以外の場合はHTTP 1.0でサポートされています）。それを無視して接続を閉じる必要があります。それは本当に単なる最適化なので、あなたはそれを安全に行うことができます。