多くのライブラリにはExpect: 100-continue、デフォルトですべてのHTTP1.1POSTおよびPUTリクエストが含まれています。
データをすぐに送信するコストが100継続のラウンドトリップを待つよりも少ないことがわかっているリクエスト、つまり短いリクエストで、クライアント側の100継続メカニズムを削除することで、知覚されるレイテンシを減らすつもりです。
Expect: 100-continueもちろん、私はまだHTTP 1.1の他のすべての優れた機能が必要なので、ヘッダーを強制終了したいだけです。私には2つの選択肢があります：
Expect:\r\n2つの間に違いはありますか？
どちらか一方のために壊れるかもしれないソフトウェアはありますか？
ヘッダーを削除しても何も壊れないはずですが、MicrosoftIISには過去にExpect問題があったことはわかっています。100 Continueたとえば、IIS5は常に100の継続応答を送信します。ですから、ライブラリでのそれの使用の少なくともいくつかは、サーバーで同様に壊れた振る舞いを回避することかもしれないのではないかと思います。
多くのライブラリはこのヘッダーを設定しているように見えますが、実際には100 Continue適切に処理されません。たとえば、を待たずにすぐにリクエスト本文の送信を開始し100 Continue、サーバーが終了する前にHTTPエラーコードを送り返す可能性があるという事実を処理しません。リクエスト本文を送信します（最初の部分はOKです。壊れているのは2番目の部分です。私の回答の後半を参照してください）。これは、一部の作者が微妙な点を完全に理解せずに他の場所からコピーしたばかりだと私に信じさせます。
Expect空白のヘッダーを含める理由がわかりません。含める予定がない場合100-continue（または他のExpect句）、ヘッダーを完全に省略してください。それを含める唯一の理由は、壊れたWebサーバーを回避することですが、このように動作するものはありません。
最後に、ラウンドトリップレイテンシを短縮することだけを考えている場合、リクエスト本文の送信をすぐに開始することは、RFCと実際には矛盾しないように思われます。（ RFCに従って）リクエスト本文を送信するのを無期限に待つことは想定されていないので、仕様に従って動作しています-とにかく送信する前のタイムアウトはゼロです。
100 Continueサーバーは、リクエスト本文の一部をすでに受信している場合、応答を送信しないように自由になっていることに注意する必要があります。そのため、送信するサーバー100 Continue、何も送信せずに完全なリクエストを待つサーバー、およびすぐに送信するサーバーを処理する必要があります。 HTTPエラーコード（417の場合もありますが、一般的な4xxコードである可能性が高い）。このように、短いリクエストには（Expectヘッダーを除いて）オーバーヘッドがないはずですが、を待つ必要はありません100 Continue。もちろん、このアプローチが機能するためには、サーバーがエラーコードを返すとすぐにリクエストを中断できるようにする必要があります（たとえば、poll()またはを使用した非ブロッキングIO select()）。
このようにすることで、レイテンシを減らしながら、小さなリクエストと大きなリクエストの間でコードの一貫性を保つことができます。欠点は、要件のいずれにも明示的に違反していなくても、RFCの作成者が念頭に置いていたものではない可能性があることです。また、ノンブロッキングIOなどをまだ実行していない場合は、後のコードがより複雑になる可能性があります。