はじめてのにき

_ WebKit proxy

w3m で JS を動かす計画の一環として、 とりあえず休日にごろごろしながら WebKit API 使った HTTP プロキシとかを作っていた。 Gtk+ port の WebKit API (WebKit は環境ごとに API が違う) はまぁなんかあまりなにもできなさそうに見えて実は結構色々できて、 普通の GET くらいはストレスなく動く感じになった。

onload までのタイミングで実行された JS はちゃんと反映されているはず。 画像とか iframe を読みに行くのとか、 layout を走らせようとするのは殺せたと思う。

Gtk+ port は、なんかヘッダだけじゃダメで、 cpp 見ないと signal の仕様とかよーわからんのがキツかった。

でもなんか request のヘッダで 書き換えれないものがあるように思うのがキツい。 wireshark で調べるに、 Cookie が通らない。 Cookie は WebKit 側で処理しちゃってもらってもいいかもだけど、 Accept-Encoding とかも書き変わっちゃって そのへん後々困るかもなぁという感じ。

書き変わってるのは、

• Accept-Encoding: gzip, compress, bzip, bzip2 => identity
• Cookie: ほげほげ => 消えた

とこの2つだけか。

あとまぁそのへん気付いたのは ログイン系の挙動がおかしすぎるからなんだけど、 ログインに関しては cookie を WebKit が処理してくれてれば 勝手にうまいこと行ってくれてもいいはずで、 このへんよくわからんちん。

選択肢としては、

1. クッキーどうにかならんかとか落ちるヘッダがあっても大丈夫かなど、もうちょっと調べてみる
2. loader 使うのはやめて、 soup で自力で html ひろってきて読ませる実装にする
3. w3m が拾ってきた html を渡す実装にする(プロキシをやめる)
4. Qt ポートも見てみる
5. WebKit いじる

などがある気がする。

クッキーはまぁ SoupCookieJar とかに自分でつっこむのもいいし、 WebKit に任せられるならそれもいい気がする。 Accept-Encoding が落ちるのは微妙だねえっていうか これいじってるのはなんでなんだ。 Gtk+ ポートがアホだからとかそんなだったら悲しいから調べる価値はありそう。 まぁ見てる感じ Qt の方が熱心に開発されてはいるんだよな。

HTML に対して loader 使うのをやめるのは悲しいけど、 まぁ実害はそんなにないかもしれない。 あーでも圧縮の展開とかは soup は面倒見てくれない感じかな。 だとするとちょいめんどいか。

プロキシをやめるのはどうせ JS の処理は proxy としてだけではうまいこといかんので、 最終形態としては悪くはないんだけど、 プロキシにしておくと wget とかからも使えていいので なるべくなら避けたい。

Gtk+ やめて Qt に行くのはまぁ十分な API があるならアリ。 ただ調べるのめんどうという理由だけで避けれるなら避けたい。 あと Chromium port の WebKit API の が upstream されたら それでも良さそうな気はする。 user script とかありそうなのは良い。

あともっともっと些細な問題として user stylesheet 読めないってのがある。 layout tests controller とか読む感じでは そもそもサポートされてなさそうな感じがするんだけど、 API はあるんだよな。 Qt もこのへんは無いように見えるのがにんとも。

(16:48)