次世代の Rack や WSGI を考えてみる - Qiita
Rack や WSGI の代わりになる仕様を考えてみました (ライブラリ (rack.rb や wsgiref.py) のほうではなく、プロトコル仕様のほうです)。自分のアイデアを書き連ねただけなので、まとまってないかもしれませんがご了承ください。 なお本稿は、今後何度か改訂すると思います。ご意見があればご自由にコメントしてください。 【対象読者】Rack や WSGI に興味のある人 【必要な知識】Rack や WSGI の基礎知識 Rack と WSGI の概要 Ruby の Rack や Python の WSGI は、HTTP のリクエストとレスポンスを抽象化した仕様です。 たとえば Rack では: 引数として、リクエストを表す Hash オブジェクトを受け取り、 戻り値として、レスポンスのステータスコードとヘッダーとボディを返します。 class RackApp def cal
WSGI/Rack/PSGIの登場の背景 - $ cat /var/log/shin
何番煎じ変わりませんが、WSGI/Rack/PSGIに関して、何でこれらが必要とされるようになったのか、歴史的経緯を踏まえて色々調べたので、記録しておきます。ただし、特に歴史的な話に関しては、ネットで自分が納得できるまで探りはしましたが、正確性を欠くかもしれません*1。間違っていたらご指摘下さい。 実行環境の多様化とWAFの乱立 結論としては、この見出しがWSGI/Rack/PSGIが生まれることとなった動機といえます。 実行環境の多様化 私が小学生ぐらいの頃、20世紀終盤でしょうか、通信速度も今に比べ格段に遅く、多分スケーラビリティなんて考えも浸透していなかった頃、WebアプリといえばCGIでPerlな時代がありました*2。そんな頃の実行環境はレガシーなApacheとmod_cgiでした。 しかし、時代と共に、数多くのリクエストを捌くことが要求されるようになると、CGIでリクエスト時に毎
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
