#>mattn あ、ども。「検証」の解釈の違いかもしれません。「100%検証」するならパーズが必要なはずで、(本来の)正規表現じゃCFGをパーズできないのは自明なので考えるまでもないだろう、と思ったのですが、最初からパーズすることは必要なくて日常出会う怪しいjsonだけ弾けることを「100%検証」と仰ってるならおかしなことはありませんね。
#どっちかというと記事そのものに対してよりは、あんまり意味を考えずにリンクだけが広まってゆくことに危惧を抱いて、何かわかりやすい記事がかけないかな、と思ったという程度のコメントです。
#http://d.hatena.ne.jp/kazuhooku/20100327/1269688828 Kahuaのhttpdもreverse proxyで使うこと前提にするならkeepaliveとかサポートしなくてもいいかもね。 #そう思います。もともとkahua-httpdはローカルで開発用途に使うことしか考えてなかったんですが、外に対するサービスに使う場合には、Reverse Proxyの後ろにおくことを想定していました。歴史的な理由でCGI/FastCGIブリッジでの運用を多用してきたんですが、いずれはkahua-httpdを拡充してそちらに移りたいなぁ、と最近は考えてます。
#というか、HTTP->CGI->Kahuaプロトコルという変換をするのは馬鹿馬鹿しい
#以前、AJPのサポートを考えた時も、HTTP->AJP->Kahuaという2段変換がアホらしいという結論に達したのだけど、よく考えたらCGI/FastCGIだって同じじゃん、と
#前にも話題に出たことあったね。
#もっと言うと、ここまでHTTPが濫用されている状況を考えたり、KahuaがHTTPアプリケーションサーバとして以外の使われ方をするケースのレアさを考えると、Kahuaが独自プロトコルを持つことそのものにも、無駄がある気がする
#Kahuaのデーモンを走らせるならsharedなサーバじゃ難しいし、VPSとかdedicatedなサーバを使うならreverse proxyで組むことはそんなに高い要求じゃないものな。
#もっとも、Kahuaプロトコルは単にHTTPから得られる情報を内部化したものをシリアライズ/デシリアライズするだけと考えれば、コストは無視できると思うけど
#もうひとつ、以前から特にyasuyukiが問題にしているUNIXドメインソケットやテンポラリファイルのパーミッション問題
#KahuaサーバとKahua-httpdとを同じユーザで実行すればこの問題は回避できる
#(通常通りkahua-spvr -H ふがほげ で起動すればkahua-spvrからKahuaサーバもKahua-httpdもspawnされるから同じユーザになる)
##Simply put, this is a proxy server that works behind a NAT,
even when the client is behind a NAT, without any 3rd party.#これあると P2P とかで使えて面白そうなんですけど、バックドアになったりしませんかね。
#ICMP echo をパケットを存在しない IP アドレスに定期的に送って、ルータをだます（？）ような感じ。
#とりあえずちゃんと通信するには双方がソフトを仕込んでる必要があり、双方にソフトが仕込めるなら何でもできちゃうんで、バックドアになる心配というのは一般のクライアント/サーバアプリと同程度じゃないかなとは思います。
#会社のポリシーでNATかけてるのを社員がこっそりトンネリングする、とかいう危険はありますが。
#ちょっとわからないのは、pwnatサーバが送るICMP echoに答えられるのはNATの外のマシンだけですよね? NAT内のクライアントAはどうやって最初にそれに応答するんだろう?
#あ、pwnatサーバのICMP echoによるprobingは、単に外向けサーバのIPアドレスを収集するだけでいいのか。とにかくそこに生きてる外向きサーバがあることがわかれば、そいつに向けて今度はUDPのprobingパケットをランダムに投げる。
#「たまたま」そのサーバがNATで、その中にいるクライアントがpwnatサーバにつなぎたいと思ってたら、同様の方法でpwnatサーバのNATのアドレスに向けてランダムにUDPのprobingパケットを投げるから、運が良ければrequest/replyがマッチしてつながる。
#んー、でもそれだとあまりに確率が低いような… もっと何かやってるんだろうなあ。
Gauche > Archives > 2010/03/28