前の記事では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とします。データが正確に圧縮されているのかどうかはややこしいので見ないことにします。ランダムっぽいデータであれば良いでしょう。
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に対応していれば十分でしょう。
どの場合もレスポンスは以下の通り
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には対応していないようです。
どの場合もレスポンスは以下の通り
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を使いこなした上で、検索システムもしっかりと作っているのでしょう。凄いなぁ。
Nortonも無茶なことしますねぇ。
CPUパワー食べるのは仕方が無いとしても、ネットワーク帯域まで食べるようですね。しかもサーバー側の・・・。いいんですかねぇ。
謎は解けた!!
NortonがAccept-Encodingを途中で取ってしまうようです。
Telnetで直に叩いたリクエストにも介入していたのがびっくりでした。
パケットの送受信レベルでの監視を行っているんですね・・・お騒がせしました。
今telnetでnaoya.dyndns.org:80に同じリクエストを送ってみたら、ちゃんとContent-Encoding: gzipが付いてました。なんででしょうね。
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リクエスト投げるだけじゃダメなのかな?