問題タブ [transfer-encoding]

gzip エンコーディングでチャンク化されたデータをどのように管理しますか? 次の方法でデータを送信するサーバーがあります。

これにはいくつかの異なるアプローチがありましたが、ここで忘れていることがあります。

与えます（また、\r\n\r\nobvの後にデータのみをデコードしようとしました）：
zlib.error: Error -3 while decompressing data: incorrect header check

したがって、データが完全な形式で受信されたら、データを解凍する必要があると考えました..

同じエラー。data[:-7]また、データの最後にあるチャンクIDとdata[2:-7]、その他のさまざまな組み合わせのために解凍を試みましたが、同じエラーが発生しました。

gzipまた、次の方法でモジュールを試しました。

しかし、それは「gzipされたファイルではありません」となります。

サーバーによって受信されたデータ (ヘッダー + データ) をファイルに記録し、ポート 80 でサーバー ソケットを作成してデータを (再びそのまま) ブラウザに提供した後でも、完全にレンダリングされるため、データは無傷。私はこのデータを取得し、ヘッダーを取り除き (他には何もありません)、ファイルで gzip を試しました。

@mark-adler のおかげで、チャンク化されたデータをアンチャンクする次のコードを作成しました。

これによりOSError: CRC check failed 0x70a18ee9 != 0x5666e236、一歩近づいたものが生成されます。つまり、次の 4 つの部分に従ってデータをクリップします。

• <chunk length o' X bytes> \r\n <chunk> \r\n

私はおそらくそこに着いていますが、十分に近づいていません。

脚注: はい、ソケットは最適とはほど遠いですが、ソケットからすべてのデータを取得していないと思ったため、このように見えますdepleted。

以下の環境下：Apache -> mod_wsgi -> python -> werkzeug

http ckunking を使用するかどうか、およびチャンクの大きさを制御するにはどうすればよいですか?

ファローアップ：

私が心配しているのは、これの違いです：

この：

最初のケースでは、werkzeug は文字列を繰り返し処理し、一度に 1 文字ずつ送信します。各文字が独自のチャンクで送信されるかどうかはわかりませんが、文字列が全体として送信される 2 番目のケースよりも遅いという事実はわかっています。

これら 2 つのケースの速度の違いは、チャンクによるものですか? それとも何か他のものですか？

Varnish 4を使用して、有効なContent-Lengthヘッダーとヘッダーなしで応答する一連のバックエンドがありますTransfer-Encoding。

クライアントからの最初のヒットで、これらのヘッダーでクライアントに応答するのではなく、Varnish はヘッダーを削除して応答Content-Lengthに追加します。Transfer-Encoding: chunked(興味深いことに、ペイロードにはチャンクが含まれていないようです。これは 1 つの連続したペイロードです)。

Content-Lengthこれは、ヘッダーに基づいてセグメント サイズ、帯域幅などの分析を行おうとする Flash ビデオ プレーヤーなどのクライアントに深刻な問題を引き起こします。彼らの分析は失敗し、マルチビットレートのストリーミングなどを行うことはできません。

私は次のようないくつかの半明白なことを試しました：

• beresp.do_stream = true
• beresp.do_gzip = false
• unset req.http.Accept-Encoding

サンプル バックエンド レスポンス:

ワニスの応答例:

オブジェクトの後続のロードでは、キャッシュへの最初のロードではなく、ヘッダーが含まれます。Content-Length

VCL: https://gist.github.com/onethumb/e64a405cc579909cace1

varnishlog 出力: https://gist.github.com/onethumb/e66a2bc4727a3a5340b6

ワニストラック: https://www.varnish-cache.org/trac/ticket/1506

HTTP プロトコルは、次の 2 つのことを示します。

• Transfer-Encodingホップバイホップ ヘッダーであり、プロキシによって削除する必要があります。
• 他のホップバイホップ ヘッダーを接続ヘッダーに追加して、プロキシにそれらを削除するように指示する必要があります。

しかし、それがすべてのホップでとにかく削除されるヘッダーであることを誰もが知っている場合Transfer-Encodingは、それを Connection ヘッダーに追加する必要もありますか?

サーバーは、リクエストの「TE」ヘッダーで指定された転送コーディングでのみデータをクライアントに送信できることを知っています（または、「TE」ヘッダーが存在せず、クライアントが HTTP/1.1 の場合はチャンクのみ）。しかし、クライアントはどの転送コーディングがサーバーによって受け入れられるかをどのように知るのでしょうか? 転送コーディングは両方の方法で使用できることを理解しているためです。

テキストとバイナリ データを受け入れることができる WEB API に XML を転送したいと考えています。トラフィックサイズの観点から転送する最良の方法は何ですか?

クリア テキストとして転送するか、バイナリ データのストリームとして転送する方がよいでしょうか?

UPNP イベントをリッスンし、http "Transfer-Encoding: chunked" をサポートしない http サーバーがあります。UPNP デバイス サービス通知をサブスクライブするとき、http v1.0 を使用しますが、HTTP 1.1 と "Transfer-Encoding: chunked" の通知を受け取ります。

サーバーから HTML ページを取得する単純な curl 呼び出しがありpreg_replace()、ページに何かを挿入し、その結果がブラウザーにエコー バックされます。

私が気づいたのは、curlがHTMLページを取得しようとしているHTTPサーバーがヘッダーを使用している場合'Transfer-Enoding: chunked、html出力は何らかの形でエンコードされ（いくつかの奇妙な兆候に気づきました）、preg_replace()呼び出しは仕事をしますが、ブラウザは取得ERR_INVALID_CHUNKED_ENCODINGして勝つだけですページをロードしません。チャンクされたエンコーディングを台無しにすることなく、ページの一部を置き換える方法が必要ですか?