先日、コンテンツをgzip圧縮して出力するMovableTypeプラグインを作成し、早速これを用いてRSSをgzip圧縮するようにしていました。RSSフィードは数十分〜数時間程度の短い間隔で頻繁にアクセスされることから、圧縮による転送量削減の効果が期待できると思ったからです。
しかしRSSリーダーの中にはgzip圧縮されたRSSには対応していないものがあるようです。そこで幾つかのクライアント/RSSリーダーについてこれを調べてみました。
サーバへのリクエスト中に Accept-Encoding: gzip,deflate
があるなしに関わらず、
index2.rdf へのレスポンスは常に圧縮されたデータが返されるという状態で、
夫々のクライアントの挙動を見てみました。
元から Accept-Encoding
を送出してくるクライアントであれば通常通りに動作し、
未圧縮のデータしか受け付けないクライアントであれば何かしら不具合が出ると予想されます。
このことから各クライアントがRSSフィードの圧縮転送に対応しているかが判ります。
アプリケーション | 表示 | 購読 | 備考 |
---|---|---|---|
はてなRSS | - | NG | フィードを登録できない。「フィードが見つかりませんでした」のメッセージ |
livedoor Reader | - | NG | フィードを登録できない。「登録可能なフィードが見つかりませんでした」のメッセージ |
Google Reader | - | OK | |
SharpReader | - | OK | v.0.9.7.0 |
Mozilla Thunderbird | - | OK | |
Mozilla Firefox | OK | OK | Live Bookmark, 1.5 |
Internet Explorer | OK | - | |
Opera | OK | OK | 9.1 |
Netscape | OK | - | 7.1 |
コンテントネゴシエーションの本来の使い方から言えば当然のことですが、 横着をして *.rdf.gz だけ用意しておくのではダメなようで orz 基本はgzip圧縮されたデータを返すけれど、 未対応のクライアント用にも生データを用意しておく必要があります。 ...って、mod_deflate を使えば一発か!
RSS リーダの中には If-Modified-Since
を解せずに
毎回フィード全体を取得していくものがあったりします。
サーバが 304 Not Modified
を返せるようになるだけで負担は大きく違うと思うので、
RSSリーダー開発者の方には是非とも対応して頂きたいところです。
更に贅沢を言えば今回調べてみた gzip 圧縮転送に対応したものが増えてくれるともっと嬉しいですね。
寄せられたコメント (全 2 件中、最新 5 件まで表示しています)
リクエスト中にAccept-Encodingがあるなしに関わらず、常に圧縮されたデータが返されるという状態です。
そのため未圧縮データを要求するクライアントに対しても問答無用に圧縮データを返すわけで、
サーバの動作としては不正なわけですね。
ご指摘のように記述が不十分で誤解を招いていましたので追記してみました。
Accept-Encodingを送ってないクライアントに対して
gzip圧縮されたファイルを返すとしたら、それはウェブサーバー側の問題ですよね。