IETFの謎ちょっと訳あって、HTTPのRangeヘッダの動作をいろいろ見ているのだが、簡単なテストに、IETFのRFCを使ってみようと考えた。plain/textだからレンジを見るにはもってこいだろう。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してから送ってくれれば良いのだが、まあ、こんなものかな。