問題タブ [chunked-encoding]

コメットテックに関する記事をいくつか読みました。それらのすべては、長寿命のHTTP応答はTransfer-Encoding：chunkedでなければならないと述べました。なぜチャンクエンコードする必要があるのか​​疑問に思います。応答がチャンクエンコードされていない場合でも、クライアントのJavaScriptは応答されたテキストを読み取って解析できますよね？

Cometの応答をチャンクエンコードする必要がある特別な理由はありますか？

チャンク エンコーディング経由で送信しようとしている本文に「\r\n」が含まれているとします。それがチャンク区切りとして解釈されないようにするにはどうすればよいですか?

例: 「あなたの基地はすべて\r\n私たちのものです」

http://en.wikipedia.org/wiki/Chunked_transfer_encoding

IBM JAX-RPC ベースの Web サービスを使用して Websphere 6.1 で Web サービスを実行しています。クライアントは、HTTP ヘッダーの transfer-encoding:chunked なしでリクエストを送信しています (コンテンツの長さを指定します)。websphere からの応答には、常に HTTP ヘッダーに transfer-encoding:chunked が含まれています。これにより、応答が複数のチャンクで送信されると思います。サービス リクエスターとサービス プロバイダーが多くの仲介者 (ファイアウォールやロードバランサー (T1/F5) など) によって分離されているシステムでは、この種のチャンキングによって大幅な遅延が発生する可能性があります。

このリンクとこのリンクは、リクエストのチャンクについて話しますが、レスポンスについては何も言及していません。

HTTP ヘッダーの応答に transfer-encoding:chunked を追加しないように websphere を構成する方法はありますか?

以下に定義されているデータコントラクトがあります。

サービス契約は次のようになります。

ホストに残りの呼び出しを行うと、データが取得されますが、Id プロパティと Name プロパティのみが入力されます。説明プロパティが null です! ClientBase から継承してチャネルを作成しています。

WCF が Id と Name をシリアル化するのに Description をシリアル化しない理由を知っている人はいますか? ホストからの応答で転送エンコーディングが「チャンク」に設定されていますが、それが何か関係があるかどうか知りたいですか?

IIS7でasp.netmvcアプリケーションを実行しています。クライアントによっては、応答が「チャンク転送エンコーディング」として受信される場合があるという問題があります。理解できないのはその理由です。これは、一部のクライアントでのみ発生します（2台のコンピューターが同じブラウザー（IE 8）を使用して同じネットワーク上にあり、全員ではない場合、またはその逆の場合でも）。

誰かが私にこれを説明できますか？

この更新が遅れて申し訳ありませんが、問題はユーザーがサーバーに到達した方法の結果であることが判明しました。ユーザーがVPN接続を介してローカルLANに接続されている場合、プロキシは回避されます。そうでない場合は、プロキシが使用されます。これにより、2つの異なる結果が得られました。

背景- C# で HttpWebRequest/HttpWebResponse を使用して、既存の Web ページを別の Web アプリケーションにストリーミングしようとしています。私が印象的な問題の 1 つは、ファイル ダウンロードのコンテンツ長を使用してファイル アップロード リクエストのコンテンツ長を設定しようとしていることですが、ソース Web ページが HttpWebResponse がない Web サーバー上にある場合に問題が発生するようです。コンテンツの長さを提供します。

質問: このケースに対応するために、このアプローチをどのように更新できますか (ダウンロード応答にコンテンツ長が設定されていない場合)。どうにかして MemoryStream を使用するのでしょうか? サンプルコードをいただければ幸いです。 特に、コンテンツの長さを提供しないソース Web サーバーの問題を回避するために、「チャンクされた」HTTP ダウンロードとアップロードを行う方法を示すコード サンプルはありますか?

ありがとう

チャンクされたHTTP応答が他の何かによって中断されることなく送信されることを確認できますか？応答（および要求）を区別する必要があります。これは、コンテンツの長さを読み取ったり、閉じた接続やノーボディ応答コードを確認したりする単純なケースではありません。

各チャンクを読み取ることはできますか？チャンクサイズが0になると、1つの応答（または要求）を正確に読み取ることができますか？つまり、他の応答の一部がインターリーブで送信された可能性はありますか？チャンク転送の仕様にはどのような種類のIDも含まれていないように見えるため、連続して中断されることなく送信されると思われます。では、複数を再アセンブルするにはどうすればよいでしょうか。

最後に、応答がチャンクで送信される場合、クライアントは元の要求以外のものを送信しますか？フロー制御とエラーチェックの流れに沿って考えていますが、それはすべて下位層で処理されるため、クライアントはこれ以上何も送信しないのではないかと思います。

ありがとう！

Grails を介してファイルをダウンロードしており、このファイルがこのユーザーによってダウンロードされたという事実を、次のようなコードで記録しています。

また、クリックごとにダウンロードの記録がいくつか表示されます。これは、Firefox によって記録されたいくつかのリクエストと、ライブ HTTP ヘッダーに表示される「Transfer-Encoding: chunked」ヘッダーと関係があると思われます。(この動作は Chromium でも見られます)

また、ターミナルにエラーが記録されていることもわかります。これはおそらく関連しており、Grails のバグであるか、ログに記録されて無視されたバグである可能性がありますが、ファイルの実際のダウンロードは停止していないようです。

理想的には、コントローラー コードを 1 回だけ実行し、チャンク ファイルをダウンロードしたいと考えています。最初のアクションでダウンロードを記録し、次にファイルをダウンロードする 2 番目のアクションにリダイレクトします。しかし、途中で別のリダイレクトを配置し、フラッシュ スコープなどを使用して 2 番目の URL を保護する必要があるのは、不十分なソリューションのようです。HTTP プロトコルまたは Grails がどのように機能するかについて私が知らないことがあるようですが、これを修正する簡単な方法があります。

何か案は ？

チャンクHTTP転送エンコーディングを使用する場合、サーバーがチャンクサイズをバイト単位で書き出し、後続のチャンクデータをCRLFで終了する必要があるのはなぜですか。

これにより、バイナリデータの送信が「CRLF-unclean」になり、メソッドが少し冗長になりませんか？

データのどこかに0x0Aの後に0x0Dが続く場合（つまり、これらは実際にはデータの一部です）はどうなりますか？クライアントは、チャンクの先頭に明示的に指定されたチャンクサイズを順守するか、データで最初に検出されたCRLFをチョークすることが期待されますか？

これまでのところ、予想されるクライアントの動作について理解しているのは、サーバーから提供されたチャンクサイズを取得し、次の行に進み、次のデータ（CRLFまたはCRLFなし）からこの量のバイトを正確に読み取り、CRLFをスキップすることです。データに従い、チャンクがなくなるまで手順を繰り返します。これは準拠した動作ですか？もしそうなら、各データチャンク後のCRLFのポイントは何ですか？読みやすさ？

私はこれについていくつかのWeb検索を行い、HTTP 1.1仕様の読み取りも行いましたが、決定的な答えは私にはわかりません。