日々の破片

_ IETFの謎

ちょっと訳あって、HTTPのRangeヘッダの動作をいろいろ見ているのだが、簡単なテストに、IETFのRFCを使ってみようと考えた。plain/textだからレンジを見るにはもってこいだろう。

が、まったくうまく行かない。

たとえば、500-1000を取得しようとすると

Content-Type: text/plain
Content-Range=bytes 500-1000/17136

で206が予測通りに返る。

が、ボディは次のようなバイト列だ。

9D-DF-65-C9-D5-75-61-4E-D2-22-C1-46-50-DF-FE-61-E3-A0-49-3B-10-7B-E8-9D-A7-（まだ続く）

ASCIIでもなければUTF-8でもない。なんじゃこれ？

ふと思い立って、というよりも最初はそこから始めるべきだったが、0-500で呼び出すとちゃんと先頭が返って来る（長さのチェックはまだしていないが、おかしかない）。

現在の予想としては、TEXTはあらかじめgzipで保管されている。

で、Content-Encodingがidentityの場合は、gunzipして送り、gzipの場合はそのまま送るのではなかろうか。

で、Rangeに対しては、Gzipされたファイルをそのまま返しているのではなかろうか。妙なバイナリで、しかも先頭が1F-8Bのマジックナンバーでもないのは、本当にgzipされたデータの途中を切り出しているからではなかろうか。

とりあえず、IETFに対してRFCをRangeで読むのは意味を持たなそうだ。

で、試しにRangeを1-10で読みだすと、案の定、次のバイト列を得た。

8B-08-00-00-00-00-00-00-03-ED

マジックナンバーの2バイト目の8Bで始まる。

Content-EncodingとCotent-Rangeの相性の悪さは最悪だが、この場合はクライアントはContent-Encodingはidentity（というか指定していない）のだから、gunzipしてから送ってくれれば良いのだが、まあ、こんなものかな。