file i/o #6: write

結局のところ、HTTP PUT で保存するようにした。

jsOAuth はリクエストを生成するためのメソッドとして、より高位な順に

  • fetchRequestToken()、fetchAccessToken()
  • get()、post()、postJSON()
  • request()

を提供している。PUT はないので新しく put() を書くか、request() を直接呼び出す必要がある。が request 自体が PUT に微妙に対応し忘れている箇所があるのでそこはちょこちょこっと修正する必要はある。

さて jsOAuth を使ったとしても、dropbox にアクセスするトランスポートはつまるところ XMLHttpRequest なのだが、xhr で PUT する場合、つまり open() 時に ‘PUT’ を指定して send() 時に文字列を引数にした場合、その文字列は UTF-8 のバイト列に変換され、リクエスト自体が Content-Type: text/plain;charset=UTF-8 とみなされる(仕様)。これでは、UTF-8 以外のエンコーディングに対応できない。

send() の引数として文字列ではなく、任意のエンコーディングのバイト列に変換した ArrayBuffer にすれば、この制限は迂回できる。最新の API の実装度に関しては Chrome と Firefox に対してだいたい 2 周遅れであるところの Opera もかろうじて ArrayBuffer くらいは対応している。しかし javascript では自前のテーブルを用意するほかに UTF-16 から任意のエンコーディングへ変更する手段がない。どのブラウザも内部では UTF-16 でテキストを保持し、自身がさまざまなエンコーディングを UTF-16 へ変換するための機構を備えているのだから、それを利用したインターフェースを javascript に公開してくれてもいいのに、ないのだ(Firefox はたぶんある)。

これを解決するには、dropbox とのやり取り自体を、ブラウザと dropbox 間で直接ではなく、ここのサーバを経由させ、サーバ上で適宜適当なエンコーディングへ変換させつつ行う必要がある。ブラウザと dropbox とのやりとりを代理で行うというのはつまり、OAuth を用いたアクセスを代理で行うということだ。サーバ上で OAuth アクセスを行うには単にこれを利用させていただくだけでいい。そして実はこの方が、dropbox から割り当てられたコンシューマ キーとコンシューマ シークレットをエクステンションのソース内に埋め込まなくてもいい(そのあたりの質問)のでむしろ筋がよかったりする。

でもなー dropbox とのやり取り自体速いわけでもないのに、ここのサーバを経由させるもっともっさり感漂うことになってしまうなー……。

Leave a Reply

Your email address will not be published. Required fields are marked *