トップ «前の日記(2015-10-24) 最新 次の日記(2015-10-29)» 編集

日々の破片

著作一覧

2015-10-26

_ 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してから送ってくれれば良いのだが、まあ、こんなものかな。


2003|06|07|08|09|10|11|12|
2004|01|02|03|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|04|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|04|05|06|07|08|09|10|11|12|
2012|01|02|03|04|05|06|07|08|09|10|11|12|
2013|01|02|03|04|05|06|07|08|09|10|11|12|
2014|01|02|03|04|05|06|07|08|09|10|11|12|
2015|01|02|03|04|05|06|07|08|09|10|11|12|
2016|01|02|03|04|05|06|07|08|09|10|11|12|
2017|01|02|03|04|05|06|07|08|09|10|11|12|
2018|01|02|03|04|05|06|07|08|09|10|11|12|
2019|01|02|03|04|05|06|07|08|09|10|11|12|
2020|01|02|03|04|05|06|07|08|09|10|11|12|
2021|01|02|03|04|05|06|07|08|09|10|11|12|
2022|01|02|03|04|05|06|07|08|09|10|11|12|
2023|01|02|03|04|05|06|07|08|09|10|11|12|
2024|01|02|03|

ジェズイットを見習え