問題タブ [transfer-encoding]

重複の可能性:
python print function in real time

データベースから大量の情報 (数百万行) を取得する python cgi Web アプリケーションを開発しています。そのために、ループを実行します (print ステートメントはループ内にあります)。

スクリプトがデータベースから取得する情報をブラウザーに継続的に出力するにはどうすればよいですか? 私の場合、ループが 1000 回実行されると仮定すると、スクリプトがすべてのループを完了した後にのみ Web ページが返されます。いくつかのオプションを使用すると、スクリプトに 5 分以上かかる場合があり、サーバーからタイムアウト エラーが発生します。リクエストのタイムアウトを回避するには、サーバー側のスクリプトが頻繁に何かを返して、サーバーが死んでおらず、結果がすぐに返されることをブラウザに保証する必要があります。HTTP ヘッダー印刷 "Content-type:text/html\r\n\r\n" を使用しています。HTTPヘッダー「Transfer-Encoding: chunked」について知りました。Pythonでどのように使用しますか? 何か提案をいただければ幸いです。どうもありがとう。

よろしく、スシル。

サーバーの応答をどのようにデコードしますか

1) 転送エンコード: チャンク 2) コンテンツ タイプ: gzip

これを手動で行う必要があり、curl を使用してリクエストを送信することはできません。生の $string からデコードする必要があります。

HTTP 応答 (php) をアンチャンクすることになっている関数を次に示します。

しかし、gzip されたコンテンツでは機能しないようです (gzinflate はこのスニペットにはありません)。返されたコンテンツに対して gzinflate を実行しようとしましたが、まったく機能しません。

何か案は？または、gzip + チャンク化された転送エンコーディングはどのように連携しますか?

ありがとう

私は本当にいくつかの洞察を得るという奇妙な問題を抱えています。さまざまなファイルをダウンロードするためのコードがあります。一部のファイルは「chunked」の値を持つ「transfer-encoding」ヘッダーを返しますが、これが問題の原因であると確信しています。

ここが本当に奇妙になるところです。Motorolla Droidを3gでダウンロードすると、すべてのバイトが読み取られる前にダウンロードが終了するため、このエンコーディングのファイルは正しくダウンロードされません。そのため、ファイルが破損しています。ただし、WiFiを使用しているまったく同じ電話では、同じファイルをダウンロードしても問題ありません。

これはサーバーの問題のように聞こえますか？アンドロイドの問題？3gの問題？私のコードの問題？

応答ヘッダーを読み取るために使用しているコードは次のとおりです。

データの転送に使用しているコードは次のとおりです。

編集 さらにデバッグすると、「transfer-encoding」ヘッダーが送信されていない場合でもまったく同じ結果が得られたため、私の問題はWifiで機能し、3gでは機能しないのと同じくらい一般的であるように思われます。

サーバーをテストし、Fiddler からチャンク リクエストを送信する必要があります。非常に単純なものを送信する必要があります。たとえば、「a」文字をコンテンツとして送信する必要があります。

Transfer-Encoding: chunked ヘッダーを設定できる Request Builder タブがありますが、Request Body を指定するにはどうすればよいですか?

以下の方法でC＃経由でメールを送信しています

デフォルトのbase64だと思います。しかし、Windows Server 2008 r2 のデフォルトの smtp サーバーを使用してメールを送信するには、どの Content-Transfer-Encoding が最適なのだろうか。

異なる Content-Transfer-Encodings の間に違いはありますか。ありがとうございました。

単純なNodeJSHTTPサーバーからのさまざまな応答を試しています。私が達成しようとしている効果は、Webページのより高速な視覚的レンダリングです。応答はtransfer-encoding: chunked（右？）でブラウザにストリーミングされるので、最初にページレイアウトをレンダリングし、遅延後に残りのデータをレンダリングできると考えていました。

問題は、すでに書き込まれたデータが十分に長くない限り、応答が送信されないように見えるres.end('world')ため、たとえば、res.write(new Array(2000).join('1'))その代わりにres.write('hello')、トリックを実行することです。

データが送信されるのに十分なサイズになるまで、ノードは書き込みをバッファリングしていますか？その場合、チャンクサイズは構成可能ですか？

送信中に「Transfer-Encoding: chunked」を使用してリクエストから POST データを読み取ろうとしていますが、すべてのデータが受信されるまでスクリプトを起動できません。PHP を取得することは可能ですか?チャンクされたリクエストが通過するときに反応できるでしょうか?

Apache で PHP 5.3.8 を使用します。

JBoss 4.2.3.GAには、transfer-encoding：chunkedで生成されているJSP応答があります。これにより、Netscalerロードバランサーは、JSPによって生成されたHTMLが可変コンテンツであると見なされるため、キャッシュされないようになっています。

しかし、max-ageが設定されている場合、転送エンコーディングに関係なく、リクエストはキャッシュされるべきではありませんか？

JSPを固定長で返すようにすることにしました（transfer-encodingがfixedに設定されるようにcontent-lengthを設定します）。。私は次のテストを行いました：

大量のコンテンツを含むtest.jspファイルを使用してJboss4.2.3.GAWebアプリケーションを作成しました。サーバーから転送されたこのJSPファイルをtransfer-encoding：chunkedでデプロイしたときに確認しました。コンテンツの全体のサイズは71.00Kbでした。

test.jspにアクセスして、さまざまな設定を試しました。

test.jspがまだtransfer-encoding：chunkedであることを確認しました。

また、jboss-4.2.3.GA \ server \ default \ deploy \ jboss-web.deployer\server.xmlを編集して設定してみました。

検証済みのtest.jspはまだtransfer-encoding：chunkedです。

私はここで何が間違っているのですか？このコンテンツをキャッシュするにはどうすればよいですか？

Web サービス応答からのすべてのヘッダーに関する Web ベースのレポートを取得したいクライアントがいます。私のクライアントもSoapUIを使用してメソッドの応答をチェックし、そのアプリケーションの応答ヘッダーを再確認できます。

PHP get_headers()およびcURLメソッドを試し、ほとんどのヘッダー パラメータにアクセスできるようになりましたが、クライアントは SoapUI を介して「transfer-encoding」および「content-encoding」パラメータも取得でき、PHP リクエストはこれらを取得しません。

私の PHP get_headers の結果 (cURL と同じ):

クライアントの SoapUI ヘッダー (異なるものだけを貼り付けました):

SoapUI のように、Web ベースのアプリケーションで PHP を介してヘッダーの完全なセットを取得することは、私にとって非常に重要です。私のクライアントは、応答がチャンク化されているか、gzip で圧縮されているかどうかを確認したいと考えています。そのようなヘッダーを達成する別の方法がありませんか?

問題

Node.JS を介して不明な長さのリソースを提供しています。このため、Content-Lengthヘッダーを設定できません。HTTP 1.1 の場合、この性質のリソースにはチャンク エンコーディングを使用する必要があります。Node.JS はこれを認識しており、次のヘッダーを使用して、独自のチャンク転送エンコーディングでデータを送信します。

これはすべて問題なく、行儀の良いクライアントに適しています。 ただし、動作があまり良くないクライアント (つまり、Android 2.2 以前) をサポートする必要があります。 これらのクライアントは、チャンク転送エンコーディングを適切にサポートしていません。

修正試行 #1

私の最初の考えは、エンコーディングをnone次のように設定することでした:

これにより、Node.JS の自動チャンク エンコーディングが無効になり、ほとんどのクライアントとの互換性が維持されます。しかし、Android 2.3 以降のクライアントは、このような偽の転送エンコード ヘッダーが表示されると咳をして窒息するだけなので、壊れてしまいました。

試行番号 2 を修正 (助けが必要な場合)

でリクエストを行うとHTTP/1.0、サーバーはチャンクエンコーディングなしで適切にレスポンスを返します:

これで問題は解決し、面倒なすべてのクライアントに対して機能するストリームを提供できるようになりました。の偽のヘッダーを送信する必要はありTransfer-Encodingません。また、コンテンツの長さを指定する必要もありません。

Node.JS の HTTP サーバーが常に HTTP/1.0 モードでサービスを提供するように強制するにはどうすればよいですか?