4

HTTP 1.0 プロトコルを介してリモート Web サイトからファイルを取得しています。使用する帯域幅を最小限に抑えるために、ファイルを取得するときに gzip を使用するとよいと思いました。

ヘッダーをどのように形成しても、応答で gzip されたコンテンツを取得しませんでしたが、ブラウザーでテストすると取得できました。また、コードを使用して、自分の Web サイトから提供される gzip 形式も取得します。

これは、サーバーが HTTP 1.1 でのみ利用可能なチャンク転送エンコーディングを使用しているためだと考えました。

プロトコルを HTTP 1.1 に切り替えました。これは以下の私のコードです。私のウェブサイトはこれに答えますが、1.0 が即座に実行するのに数秒かかります。リモート Web サイトで試してみると、応答せずに永遠にロードし続けます。

私の質問は、なぜ 1.1 はそんなに遅いのですか?. 不正なヘッダーまたは何かを使用していますか? また、なぜ私のページは応答するのに、他のページは応答しないのですか。入力はありますか？ありがとう。

$header = array(
    'http' => array(
    'method'  => 'GET',
    'header'  => 'Accept-Encoding: gzip\r\n' .
    'User-Agent: test\r\n)' .
    'Accept-Charset: ISO-8859-1,utf-8\r\n' .
    'Accept-Encoding: gzip, sdhc, deflate\r\n' . 
    'Host: www.mysite.test.com\r\n' .,
    'protocol_version' => '1.1\r\n'
);

$context = stream_context_create($header);
$file_string = file_get_contents('www.mysite.test.com/test.txt', false, $context);

編集：サーバーのキープアライブ制限に達するまで、接続を開いたままにしておくようです。彼らのウェブページから私の答えを得るのに約1.1分かかりました. 次に、接続を閉じる方法を理解する必要があります。それ以外の場合は機能するようです。

4

1 に答える 1

1

うーん…しばらく頭を壁にぶつけた後、答えは明らかだったようです。

Connection を一番上に移動したところ、突然機能しましたが、gzip 設定が機能しなくなりました。だから私は順序が重要であると思われる理由を理解しようとしました.\r\nが正しく評価されない原因となる"の代わりに一重引用符で引用していたようです.少なくとも私はそれが問題だったと思います.それは今働いているようです. . とにかくみんなありがとう... こんな単純なミスをするのは嫌だ...

もう一度編集してください: サイトから gzip を取得していないようですが、私のサイトでは動作します。ブラウザーからヘッダーをコピーして、何が起こるか見てみます。

編集 2: では、どうぞ！意図したとおりに機能します。たぶん、彼らはどういうわけかユーザーエージェントなどをフィルタリングしていたのでしょう。

編集 3: 同じファイルを複数回ダウンロードすると、本当にランダムな結果が得られます。gzip されることもあれば、そうでないこともあります。彼らのサーバーは、2 つのヘッダーのうちの 1 つをランダムに提供してくれます。唯一の違いは、Vary: Accept-Encoding と Content-Encoding: gzip です。処理できると言ったら、常にgzipを送信すると思いましたか？私のサーバーは常にgzipを提供しているようです。

編集 4: 何らかの理由で、ユーザー エージェントで以前の MSIE 5.0 バージョンを使用しているときに、gzip:ed が提供されたり、圧縮解除されたりすることがあります。gzip を処理できるユーザーエージェントに引き渡すことだけは理解できましたが、少なくとも一貫性があるはずです。ともかく。問題は解決しました、ありがとう。

于 2013-03-10T16:20:04.237 に答える