2005年02月08日

RSS検索サイトは検索結果を圧縮して返すか

前の記事ではRSS検索サイトがステータスコード304を返すか調べましたが、今回はRSS検索サイトが検索結果を圧縮して返すかどうか調べてみようと思います。

検索結果を圧縮して返す、というのは、Accept-Encoding付きのHTTPリクエストを送ると、ちゃんと検索結果(コンテンツ)をAccept-Encodingにより示された方法でエンコードして返してくれるか、ということです。

といっても、Heimdallrまだ本体がAccept-Encodingに対応していないので、今回の結果がどうあれ、キーワードチャンネルがすぐAccept-Encodingに対応することは無いです(本体が先です)。

さて、HTTP 1.1のAccept-Encodingに指定できる値を見てみると、以下の4つです。

gzip compress deflate identity

identityは、圧縮せずに結果を返せ、という意味を持っていますのでこれについては特に調べません。残りの3つを調べます。

調べ方は、まず以下のようなリクエストをサーバに送信します。

GET http://naoya.dyndns.org/feedback/app/rss?keyword=RSS HTTP/1.1
Accept-Encoding: gzip
User-Agent: Test Application
Host: naoya.dyndns.org
Pragma: no-cache

URLとAccept-Encodingフィールド、Hostフィールドは変化します。
でもってレスポンスヘッダにContent-EncodingフィールドがあればOKとします。データが正確に圧縮されているのかどうかはややこしいので見ないことにします。ランダムっぽいデータであれば良いでしょう。

Feedback

gzipの場合のレスポンスは以下の通り

HTTP/1.1 200 OK
Date: Tue, 08 Feb 2005 12:50:28 GMT
Server: Apache/1.3.28 (Unix) mod_gzip/1.3.26.1a mod_perl/1.29
Vary: *
Last-Modified: Tue, 08 Feb 2005 12:05:45 GMT
Content-Type: text/xml; charset=UTF-8
Content-Encoding: gzip
Content-Length: 3763
X-Pad: avoid browser bug

ばっちり対応しています。データもランダムっぽいのでOKでしょう。
X-Padフィールドがちょっと謎ですが、 古いNavigatorのバグ回避用のようですね。へぇ。

gzip以外のレスポンスは以下の通り

HTTP/1.1 200 OK
Date: Tue, 08 Feb 2005 12:51:01 GMT
Server: Apache/1.3.28 (Unix) mod_gzip/1.3.26.1a mod_perl/1.29
Vary: *
Last-Modified: Tue, 08 Feb 2005 12:05:45 GMT
Content-Type: text/xml; charset=UTF-8
Transfer-Encoding: chunked

残念ながら対応無し。
Serverフィールドからするとmod_gzipが入っているようなのでそれが機能しているだけなのかもしれませんね。でもgzipに対応していれば十分でしょう。

Bulkfeeds

どの場合もレスポンスは以下の通り

HTTP/1.1 200 OK
Date: Tue, 08 Feb 2005 13:32:39 GMT
Server: Apache/1.3.33 (Unix) mod_perl/1.29
Content-Type: text/xml; charset=utf-8
X-Cache: MISS from bulkfeeds.net
Transfer-Encoding: chunked

残念ながらAccept-Encodingには対応していないようです。

未来検索livedoor

どの場合もレスポンスは以下の通り

HTTP/1.1 200 OK
Date: Tue, 08 Feb 2005 13:36:10 GMT
Server: Apache/1.3.31 (Unix) mod_perl/1.29
Set-Cookie: sledge_sid=c0d1b004b3b68b24b952baff2448a9f8; path=/
Content-Length: 7618
Content-Type: text/xml; charset=UTF-8
X-Cache: MISS from rss.sf.livedoor.com

残念ながらAccept-Encodingには対応していないようです。
未来検索livedoorは、Bulkfeedsから派生したという話ですが、Bulkfeedsには無いContent-Lengthを返しますね。マメですね。
ところでこのクッキー情報は何に使っているのでしょうねぇ・・・

もぶろげっと β

どの場合もレスポンスは以下の通り

HTTP/1.1 200 OK
Date: Tue, 08 Feb 2005 13:40:07 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
X-AspNet-Version: 1.1.4322
Set-Cookie: ASP.NET_SessionId=1tbq5rm1nz3pxsfjszjjnyyv; path=/
Cache-Control: private
Content-Type: application/xml; charset=utf-8
Content-Length: 15218

これも残念ながらAccept-Encodingには対応していないようです。
ところでこれにもクッキー情報があります。 でもASP.NETによって作られているところを見ると、ASP.NETが勝手に付けちゃった、という気もしますね。

結論

というわけで、Feedbackがgzipに対応しているだけ、という結果になりました。RSS検索サイトって結構トラフィック多いような気がするんですけど大丈夫なんですかね。

しかし、前の記事記載のIf-Modified-Sinceの件といい、Feedbackのシステムはしっかりとしてますね。細かいところまで配慮が行き届いているような気がします。唯一隙があるとしたらContent-Lengthを返さない(gzipの場合以外)ことくらいでしょうか。
細かいところまでの配慮と言っても、Apacheが勝手にやっているのかもしれません。私はApacheが付けたフィールドと、検索システムが付けたフィールドを切り分けできません。
でも、同じApacheを使っていてもBulkfeedsや未来検索livedoorは同じようになっていないわけですから、きっとFeedback開発者のnaoyaさんが、しっかりとApacheを使いこなした上で、検索システムもしっかりと作っているのでしょう。凄いなぁ。

投稿者 MASATO : 2005年02月08日 22:56 | トラックバック
コメント

Nortonも無茶なことしますねぇ。
CPUパワー食べるのは仕方が無いとしても、ネットワーク帯域まで食べるようですね。しかもサーバー側の・・・。いいんですかねぇ。

Posted by: MASATO : 2005年02月10日 22:12

謎は解けた!!
NortonがAccept-Encodingを途中で取ってしまうようです。
Telnetで直に叩いたリクエストにも介入していたのがびっくりでした。
パケットの送受信レベルでの監視を行っているんですね・・・お騒がせしました。

Posted by: 瞳子 : 2005年02月10日 07:58

今telnetでnaoya.dyndns.org:80に同じリクエストを送ってみたら、ちゃんとContent-Encoding: gzipが付いてました。なんででしょうね。

Posted by: MASATO : 2005年02月09日 22:09

GET http://naoya.dyndns.org/feedback/app/rss?keyword=RSS HTTP/1.1
Accept-Encoding: gzip
User-Agent: Test Application
Host: naoya.dyndns.org
Pragma: no-cache
だけを送ったら

HTTP/1.1 200 OK
Date: Wed, 09 Feb 2005 07:40:49 GMT
Server: Apache/1.3.28 (Unix) mod_gzip/1.3.26.1a mod_perl/1.29
Vary: *
Last-Modified: Wed, 09 Feb 2005 07:40:52 GMT
Content-Type: text/xml; charset=UTF-8
Transfer-Encoding: chunked
でした・・・・直にTelnetからproxyにhttpリクエスト投げるだけじゃダメなのかな?

Posted by: 瞳子 : 2005年02月09日 16:46
コメントする









名前、アドレスを登録しますか?