1つのことをまっすぐにすることはできません。4.4.5のRFC 2616 には、 Message Length「 」と判断できると記載されていますBy the server closing the connection.。

これは、サーバーがヘッダーに no を含む応答で応答する (たとえば、大きな画像を返す) ことは有効であることを意味しますが、クライアントは接続が閉じられるまでContent-Lengthフェッチを続け、すべてのデータが既に処理されていると想定する必要があります。ダウンロードしました。

しかし、接続がサーバーによって意図的に閉じられたことをクライアントが確実に知るにはどうすればよいでしょうか? データの送信中にサーバー アプリがクラッシュした可能性があり、サーバーの OS がFINパケットを送信して、クライアントとの TCP 接続を適切に閉じる可能性があります。

Node.js に組み込まれている HTTP クライアントは、リクエストのパイプライン処理をサポートしていないようです。しかし、バックグラウンドでパイプラインをセットアップするエージェントを作成できる可能性があることに気が付きました。応答データを本来あるべき状態に戻す際に問題が発生する可能性がありますが、おそらくエージェントはいくつかのソケット オブジェクトを偽造して、HTTP クライアントを通常どおりに動作させることができますか?

これは行われましたか？または、パイプラインをサポートするメインのドロップイン代替である代替 HTTP クライアントはありますか? （最終的にはAWS SDKで使いたいので互換性が必要です。）

Accept-Ranges: noneクライアントに範囲リクエストを試行しないようにアドバイスするようにサーバーに設定できることを理解しています。

サーバーに変更を加えることなく範囲要求を試行しないようにブラウザーに指示する方法があるかどうか疑問に思っています。

たとえば、Chrome や Firefox に、ブラウザが範囲リクエストを行わないように切り替えることができる設定はありますか?

rfc2616の http 標準を読んでいます。の形式を取得したいと思いますIf-None-Match。それは私に与えます：

If-None-Match = "If-None-Match" ":" ( "*" | 1#entity-tag )

とは何1#ですか? または線量1#entity-tagは正確なETag?

RFC2616による

Allow entity-header フィールドには、Request-URI によって識別されるリソースによってサポートされる一連のメソッドが一覧表示されます。このフィールドの目的は、リソースに関連付けられた有効なメソッドを受信者に厳密に通知することです。

「Allow ヘッダー フィールドが 405 (Method Not Allowed) 応答に存在しなければならない」ことを義務付けています。

さらに、

このフィールドは、クライアントが他の方法を試みるのを防ぐことはできません。ただし、Allow ヘッダー フィールドの値によって示される指示に従う必要があります。許可されるメソッドの実際のセットは、各リクエスト時にオリジン サーバーによって定義されます。

したがって、広く使用されている REST API の場合、GET、PUT、POST、HEAD、PATCH(?) などの他の関連する HTTP メソッドへの応答に Allow ヘッダーを設定すると、機能を発見しようとしているクライアントに役立つ可能性があります/リソースのサポートされている操作。

ただし、このトピックに関する Google 検索では、役立つ結果が得られませんでした。したがって、SO コミュニティからの情報を探しています。

TL;DR: トピックが言うように - マルチパート ポスト ボディを送信する必要があるのは、接続の確立後に受信した応答ヘッダーを処理した後のみです。

libcurl のドキュメントによると、CURLOPT_HEADERFUNCTION は、ヘッダー データを受信するとすぐに libcurl によって呼び出されます。 しかし、簡単な調査の後、これは起こりませんでした。

再現方法:

コールバック:

リクエストの短い本文:

そして、次のログを受け取ることができます (c++11 クロノエポックからの多数の時間):

タイプ [0] データ: [SSL 関連のもの]

タイプ [0] データ: [100 を待って終了-続行]

ReadFromStateCallBack 1455532592078426519

...

ReadFromStateCallBack 1455532592507779449

HeaderCallback 1455532592937695923 [HTTP/1.1 100 継続]

HeaderCallback 1455532592937713786 [日付: 2016 年 2 月 15 日月曜日 10:36:32 GMT]

タイプ [0] データ: [サーバー ATS はブラックリストに登録されていません]

HeaderCallback: 1455532593030759917 [HTTP/1.1 401 Unauthorized]

ヘッダーからの追加情報

また、ご覧のとおり、libcurl は 100-continue ヘッダーを処理する必要がありますが、ヘッダーを処理するためのコールバックはデータの送信後にのみ呼び出されます。

また、必要なすべてのヘッダーが受信されたようです。tcpdump の例:

13:36:30.425361 IP 192.168.1.70.41895 > 74.112.184.85.https: フラグ [S]、seq 164841209、win 29200、オプション [mss 1460、sackOK、TS val 2164947 ecr 0、nop、wscale 7]、長さ 0

13:36:30.639293 IP 74.112.184.85.https > 192.168.1.70.41895: フラグ [S.]、seq 1336121630、ack 164841210、win 14480、オプション [mss 1460、sackOK、TS val 2083933652 ]、長さ 0

13:36:30.639337 IP 192.168.1.70.41895 > 74.112.184.85.https: フラグ [.]、ack 1、win 229、オプション [nop、nop、TS val 2165000 ecr 2083933652]、長さ 0

13:36:30.640031 IP 192.168.1.70.41895 > 74.112.184.85.https: フラグ [P.]、seq 1:297、ack 1、win 229、オプション [nop、nop、TS val 2165000 ecr 2083933652]、長さ 296

13:36:30.853750 IP 74.112.184.85.https > 192.168.1.70.41895: フラグ [.]、ack 297、win 122、オプション [nop、nop、TS val 2083933866 ecr 2165000]、長さ 0

13:36:30.861507 IP 74.112.184.85.https > 192.168.1.70.41895: フラグ [P.]、seq 1:2690、ack 297、win 122、オプション [nop、nop、TS val 2083933874 ecr 2165000]、長さ 2689

^^^^^ - ここです。

13:36:30.861524 IP 192.168.1.70.41895 > 74.112.184.85.https: フラグ [.]、ack 2690、win 271、オプション [nop、nop、TS val 2165056 ecr 2083933874]、長さ 0

13:36:30.862654 IP 192.168.1.70.41895 > 74.112.184.85.https: フラグ [P.]、seq 297:423、ack 2690、win 271、オプション [nop、nop、TS val 2165056 ecr 2083933874]、長さ 126

13:36:31.076949 IP 74.112.184.85.https > 192.168.1.70.41895: フラグ [P.]、seq 2690:2741、ack 423、win 122、オプション [nop、nop、TS val 2083934090 ecr 2165056]、長さ 51

13:36:31.077286 IP 192.168.1.70.41895 > 74.112.184.85.https: フラグ [P.]、seq 423:693、ack 2741、win 271、オプション [nop、nop、TS val 2165110 ecr 2083934090]、長さ 270

13:36:31.330808 IP 74.112.184.85.https > 192.168.1.70.41895: フラグ [.]、ack 693、勝利 130、オプション [nop、nop、TS val 2083934344 ecr 2165110]、長さ 0

13:36:32.078397 IP 192.168.1.70.41895 > 74.112.184.85.https: フラグ [P.]、seq 693:870、ack 2741、win 271、オプション [nop、nop、TS val 2165360 ecr 2083934344]、長さ 177

13:36:32.078533 IP 192.168.1.70.41895 > 74.112.184.85.https: フラグ [.]、seq 870:2218、ack 2741、win 271、オプション [nop、nop、TS val 2165360 ecr 2083934344]、長さ 1348

繰り返し送信データ

SSL 接続のため、-A を使用して tcpdump を表示できません。ヘッダーが提案された部分で受信されたことを確認してください。

ソフトウェア：

• libcurl(7.36)
• コンパイラ GCC(4.8.4)

PS私にとって、libcurlは[RFC 2616(8.2.4)]に対して間違った動作をしているようです( https://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html )

PPS 存在する場合は同じ動作 接続: ヘッダーを閉じます。

この SO の質問に対する回答を見てきました:ファイルのアップロードで "Content-Type" を信頼する

そして、それらは直感的に理解できます。

ただし、RFC 2616 Sec 7.2.1 によると、

「コンテンツ タイプ フィールドでメディア タイプが指定されていない場合に限り、受信者は、リソースの識別に使用される URI のコンテンツおよび/または拡張子の検査を介して、メディア タイプの推測を試みることができます (MAY)。 "

RFC のこの部分をサーバーに適用する際の理由を知りたいのですが、なぜサーバーはクライアントのヘッダーを信頼し、ヘッダーが欠落している場合にのみコンテンツ インスペクションにフォールバックする必要があるのでしょうか。効率は、私が考えることができる1つの理由です。それとも、RFC を誤解しているのでしょうか?

私はETagキャッシュにヘッダーを使用しており、ブラウザーは対応するIf-None-Matchヘッダーを送信します。最初は、これらのヘッダーを単純に比較したところ、うまくいきました。

後で、rfc2616がエンティティのリストを許可することに気がついたので、修正しました。問題は、修正が使用されるかどうかです...

• If-None-Matchブラウザは、複数のエンティティを含むヘッダーを持つリクエストを発行することがありますか?
• 他の現実世界での使用はありますか?

例：

• URL http://.../foo/download.csvを提供します
• Web クライアント (MS オフィス) が上記の URL を開き、http OPTIONS リクエストでhttp://.../foo/にアクセスしようとします (理由はよくわかりません) 。
• 上記の URL が存在しないため (GET 要求の場合でも)、アプリは 404 を返します。

すべての OPTIONS リクエストは 405 を取得する必要があると思います。URL が GET または POST 経由でアクセスできるかどうかは問題ではありません。

これは http 仕様と一致しますか?

405 の方が適していると思う理由は次のとおりです。OPTIONS 要求がある場合、パスを見たくないからです。パスがどのように見えるかは気にしません。常に同じ答えがあるはずです。許可されていません。

これまでのところ、状況によって異なります: GET ビューが登録されている場合は 405 を返します。それ以外の場合は 404 が返されます。

更新: 404 対 405

HTTP-Spec 405 メソッドは許可されていません

Request-URI で識別されるリソースに対して、Request-Line で指定されたメソッドは許可されていません。応答には、要求されたリソースの有効なメソッドのリストを含む Allow ヘッダーが含まれている必要があります。

ソース: https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.6