手作りネットプロトコル工房コミュのHTTPサーバーの CHUNKED対応

http://www.jmarshall.com/easy/http/#http1.1c2

HTTPを使ってサーバークライアント間でデータをやり取りする時、可変長のデータをやり取りする事も多い。 HTTPサーバーとしては、あらかじめ送信するデータのサイズがわかっていたほうが仕事が簡単に決まっているけど、CGI なんかを実装する事を考えると、前もって送信するデータのサイズがわからない場合も少なくない。

バッファリングして、全体像をつかんでから送る方法もあるけど、それはちょっと...。

そういう場合のために CHUNKED ENCODING というような呼ばれ方をするデータ転送方法がある。これは送信するとき、データをブロックごとに区切ってしまって、区切ったブロックの先頭にこれから送るブロックのサイズをつけておくのだ。データの転送終了の合図はブロックサイズ０と決める。これで可変長のデータでも、あらかじめデータのサイズを調べることなく、送ることが出来る。

HTTPの仕様書を読むと、HTTPクライアントプログラムはこの Transfer-Encoding : chunked なデータを受け入れることが出来なければいけない... と書かれている。なるほど。

でも良く考えてみると、クライアントが可変長データブロックをサーバーに送りつけるということも充分考えられるのだ。つまり POSTでデータが上がってくる時、これが可変長で Transfer-Encoding : chunked として送信される事も、仕様上は十分可能なのだ。

でも、今のところ、そういうことをするブラウザはなさそうだ。

◇

こういう風にインターネットでとても重要な位置を占めているプロトコルでさえ、とてもあいまいなのが現状なのだ。こういうあいまいなプロトコルは、プログラムの互換性の低下と、プログラムの開発費用の増大を招く。

今から、「じゃぁウェブブラウザを独自に開発しまーす」なんていう人がいるだろうか。いないはずだ。 HTTPとHTMLのあいまいな仕様の隙間にゴッチャリとたくさん落ちている、言葉にならないデファクトスタンダードをいっこいっこ調査していかなければならないからだ。こういう恐ろしい橋をわたる危険を、懸命なプログラマであれば、避けるものだ。

◇

逆にプロトコルはきっちり決まってるけど、ほとんどちゃんと実装されてないっていうケースもある。

HTTPバージョンチェックの機能なんか、危なさそうだ。

HTTPのバージョンチェックは結構センシティブな問題だ。 HTTP/1.0 と HTTP/1.1 をキチンと分岐して処理しなければいけないからだ。仕様上は一応HTTP/1.2 とか HTTP/1.3 とかを実装する事も考えられて作られている。でもこんなの実装しているソフト、ないんだろうなぁ...。

という事は将来誰かが HTTP/1.2 というものを考えてそれに移行しよう！と高らかに声を上げても「いや、でも対応にコストがかかるからそれは止めようよ...」と引け腰な意見が増えて、結局お流れになるという憂き状況を招くのだろう。「仕様書はちゃんとこうなってるのに！」「いやそれは理想論で...」とかそういう後ろ向きな意見が社会を埋め尽くす。

だから、結局仕様がきちんと定義されていても、意味がないのだ。
こういうプロトコルは時代の変化に対応する力を失っているといえる。

世の中のプログラマってバカばっかりと思わないだろうか。

プログラマだけじゃない。仕様に忠実につくるプログラマがいても「え～でもどうせ動作は同じなんでしょ？じゃぁ某IEの方が最初からインストールされているし、楽じゃん」とかいうような気の抜けたユーザーが世の大半を占めている限り、仕様に忠実な清く正しいプログラマは、社会のつまはじき者として、虐められ続けるわけだ...。

◇

汚い仕様のプロトコルにはもうウンザリだ。 ... いつか全部作り変えてやる。