読者です 読者をやめる 読者になる 読者になる

俺の報告

RoomClipを運営するエンジニアの日報(多分)です。

日報 #94 - POSTリクエストのボディ部分について

いやはや、
苦手なことを克服する必要性って色々議論があるじゃないですか。
基本的に僕は、苦手なら他人に任せりゃいいって思うんです。
その方が世界中がハッピーなはずです。
ですが、世界はそんなに不寛容ではなく、ハッピー判定の時間的猶予を十分に確保してくれたりします。
「最初はアンハッピーだけど、長いスパンで見るともっとハッピーになれる」という感じで。

そうなると、見方が変わってきます。
苦手なものの中に「避けては通れねぇなぁ…」というものが幾つか浮き上がってくるのです。
そうして、重い腰を上げて取り組んでいくというようなことが何年かスパンでよくあります。
勘違いだったら悲惨なので事は慎重に進めますが。
とにかく、
今は丁度そんな感じです。

さて、
本日は少しだけ技術的な話。とはいっても基本的な話。
便利な高級言語のせいで、すごい基本的な話をまったく知らずに高等なことが出来てしまう世の中です。
例えば僕はPOSTリクエストのContent-typeの種類と書き方について、正確には知りませんでした。
ということでその話。

とあるphpスクリプトに直接POSTリクエストを叩き込みたくなる時がございました。
もちろんDHCやらCurlやらでやればいいのですが、ふと、
リクエストボディの中身で連想配列ってどうやって書いているんだろうって疑問に思いました。
まさかPHP用のシリアライズとかじゃねぇよなぁと思いつつ、
GETでもid[0]=1&id[1]=2ってやれば配列なんだからきっとそれと同じ書式だろうとも考えられる。

結論から言うと、そうでした、ってだけの話なんですが、その文字列のルールを決めているContent-typeは、
application/x-www-form-urlencoded なるものだということを初めて知りました。
ファイルなどを送る時は
multipart/form-data なるものをつかうようです。
これに関する規約団体の仕様書などを探しましたが、あまりいいものがなかったので、例にもよってW3Cを引用します。
http://www.w3.org/TR/2007/REC-wsdl20-adjuncts-20070626/#_http_x-www-form-urlencoded
ちゃんとスキームとして規定されているようですね。
他の項目と合わせてよく読んでいくとどうやら application/xml とか multipart/form-data を使うべきのようです。

ではバイナリも送れる multipart/form-data の書式について少し理解しておきます。
サンプルとしてはDHC(Chrome Extension)を使いますね。

まずリクエストヘッダのContent-Typeは下記ように書きます。

multipart/form-data; boundary=hogehoge

このboundaryはメールとかでもよくあるように、データの境界線を示します。
そしてリクエストヘッダ部分は、

--hogehoge
Content-Disposition: form-data; name="key"

value
--hogehoge--

このように書きますと、
$_POST['key'] = "value"のように格納されます。
いや便利ですね。
これにてPOSTリクエストのボディエンティティに対するイメージがしっかりしました。
あぁよかったです。

現場からは以上でした。