lighttpd で X-Reproxy-URL ヘッダを使えるようにするモジュール mod_reproxy を書いた - KAYAC Engineers' Blog
ウェブアプリケーションにおいて、認証がかかっている画像や大きなファイルを配信する場合には、Perlbal 等でサポートされている X-Reproxy-URL ヘッダが有効なことが知られていて、その理由としては、 (メモリを大食いする) アプリケーションサーバのプロセスを転送終了まで占有しない HTTP ベースの分散ファイルシステムとリバースプロキシが直接交信するので、ネットワーク負荷が低い といった点が挙げられます。「でも、Apache は X-Reproxy-URL ヘッダをサポートしてないんだよねー」という話が、先日の YAPC::Asia 2009 においても話題になっていました[要出典]。回避策としては、ワンタイムURLのような手法もあるのですが、セキュリティな懸念もあります。 何とかしたいと思っていたのですが、lighttpd 1.4.x 系では fastcgi や proxy
lighttpdでモジュールを書く際に気をつけること - グニャラくんのグニャグニャ備忘録@はてな
lighttpdのモジュールを書くことを覚えてしまったせいで、 ついついlighttpdのモジュールで仕事を進めてしまうクセがつきました。 「なんでもおもっど」状態です。 全パスに対するアクセス数をTokyoCabinetに記録したり、 特定のパスに対してはmemcachedから値を取得したり、 Sennaで特定のキーワードにリンクを付与したり、 まあ、やりたい放題です。パフォーマンスも出てます。 ああ毛が立っちゃう。 lighttpdのbufferやarrayを使えば、 メモリリークなどに悩まされることはほぼありません。 意外と安定して開発・稼動できたので正直ビックリしています。 まあ、cookieをパースしたりする便利関数がないので、 そこらへんは根性で書く必要はあります。 どうにかしてくれよ（そろそろ飽きてきた）。 lighttpdのモジュールの欠点は、 ビルドシステムがちゃんとして
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
