HTTPリクエストヘッダーExpectについても詳細に説明されています

クズども · 2021年4月22日 15:32:09 に投稿

文書紹介:ハイパーリンクのログインが見えます。

カールを通じて相手のインターフェースに連絡したところ、タイムアウト現象が非常に深刻であることが判明し、相手のインターフェース担当者に尋ねたところ、追加が必要だと言われました:

追加してみると本当にうまくいくと感じたので、使い方を調べてみました。 POSTにcurlを使用する場合、「POSTデータが1024バイトより大きい」場合、curlは直接POSTリクエストを開始するのではなく、2つのステップに分割されます。

Expect: 100-continue

1. Expect:100-continueを含むリクエストを送信し、サーバーにデータの受諾を求める

2. サーバーから返答された100-continuの返信を受け取った後、データはサーバーにPOSTされます

しかし、これにはいくつかの問題があります。

すべてのサーバーが100-continueに正しく応答するわけではありません。例えばlighttpdは417の期待失敗を返します。

遅延を引き起こし、クライアントが最初のExpect:100-continueを送信する際、サーバーの応答を待ってからリクエスト本体を送信する必要があります。

相手のサーバーが1024バイトを超えるPOSTリクエストを拒否しないと確信できるなら、この方法を使わず、上記の2つの副作用を避けられます。解決策は記事の冒頭で述べたものです。

約100人が続けています

その目的は以下の通りです:

これにより、クライアントはサーバーがリクエストデータを受け取る意思があるかどうかを判断し、サーバーが受け取る意思があれば実際にデータを送信します。

クライアントの行動:

100回のコンティニューを送信したクライアントは、サーバーからの応答を永遠に待つべきではなく、一定時間のタイムアウト後にクライアントは直接エンティティを送るべきです。

サーバー側の動作:

サーバーが100の継続リクエストを受け取ると、100の継続を返すかエラーコードを送信します。サーバーは、100コンティニューを送らないクライアントに100コンティニューを送ることは決してできません。しかし、一部のサーバーはそうです。 IIS 5が誤って100-コンティニュー応答を送信している

もしサーバーがクライアントのボディを100の継続応答を送る前に受信した場合、それはクライアントがデータの送信を開始することを決めたことを意味します。つまり、サーバーはもはやクライアントに100の継続を送信できなくなります。
.NETのExpect Off Expect設定コードは以下の通りです:

ログインが見えます。

RestSharpの構成は以下の通りです:

ログインが見えます。

クズども · 2025年4月6日 21:52:04に投稿

HttpClientクロージング方法

ログインが見えます。

又は

ログインが見えます。

HTTPリクエストヘッダーExpectについても詳細に説明されています

関連記事

閲覧したセクション