Apacheのmod_rewriteをmod_mrubyによって無くす事ができるか | 人間とウェブの未来
Apacheのmod_rewriteをmod_mrubyによって無くすことを考えた時に、現状mod_rewriteでやれることをmod_mrubyに置き換えるとどうなるのかを検証・考察してみました。 なぜかというと、mod_rewriteで困っているような呟きをいくつか見て、以下のように思ったからです。 apacheでrewriteが面倒な人はmod_mrubyやmod_luaを使っちゃっても良い気がするなー。誰かがやり出すとどんどんやり出しそう。性能劣化も少ないし。 — MATSUMOTO, Ryosukeさん (@matsumotory) 10月 21, 2012 以前こんな記事「Apache 2.4.1のmod_luaでApacheに介入する（mod_rewriteの終焉？）」を書いたのですが、これも深く関連しています。現状、いったいmod_mrubyはどこまでmod_rewrite
Apacheが%2Fを勝手にデコードして生きるのが辛いとき - かみぽのメモ
mod_rewriteでの最後の砦 - As a Futurist...をみて、僕もApacheでURLに%2Fを含むリクエストをリバースプロキシするときに困ったことがあったなーというのを思い出した。 AllowEncodedSlashes On RewriteRule ^/(.*)$ http://backend/$1 [QSA,L,P]みたいな設定を書いてるときにfrontendに http://frontend/keyword/Fate%2Fstay+nightなリクエストが来ると、この設定だとbackendには http://backend/keyword/Fate/stay+night%2FがデコードされたURLにプロキシしてしまう！ %2Fのままプロキシするには以下のように設定をすればよい。 AllowEncodedSlashes On RewriteCond %{THE_RE
mod_rewriteでの最後の砦 - As a Futurist...
Web サーバ勉強会＃3で話してきた内容です。mod_rewrite と mod_proxy_balancer 使って、L7 ロードバランサを作ろうとしたときにハマった話なんですが、すごい特定の限られた条件だし、そもそも大してクリティカルじゃないのですが、まぁまぁ面白い話題だと思うので紹介しておきます。 mod_proxy で最後の砦を作る時 ただのリバースプロキシだったり、L7 ロードバランサだったりの用途で、Apache の mod_proxy(mod_proxy_balancer)を使うことはたまにあると思います。RewriteMap とか、ルールのマッピングを外部ファイルにできたりするので結構柔軟に色々できます。 その際に色々と振り分けのルール付けを設定した後で、最後に「どれにも当てはまらない時はとりあえずここに振り分けさせる」というルールを書くときみなさんどうしてますか？Apac
ウノウラボ Unoh Labs: mod_expires と mod_rewrite を使ってウェブサーバへのアクセスを減らす方法
最近、雨の日が続いて自転車通勤ができていない naoya です。 今日は、先週ぐらいからフォト蔵に導入した Apache で mod_expires と mod_rewrite を使ったウェブサーバへのアクセスを減らす方法を紹介します。 通常のウェブサーバは、更新されていないリリースに対してアクセスすると、ステータスコード 304 とIf-Modified-Since ヘッダをつけて応答データを返しますが、CSS や JavaScript など比較的更新頻度の少ないファイルに対して、毎回応答を返すのはウェブサーバから見ると無駄なアクセスです。 Apache の mod_expires と mod_rewrite を使うと、この無駄なアクセスをブラウザキャッシュを有効活用にすることにより、静的なファイルに対するアクセスを減らすことができます。 まず、仕組みから説明すると、とても単純で mod
cyano: mod_expiresとmod_rewriteを使ってサイトの帯域節約と体感速度を向上させる方法
普通の帯域節約術としては、mod_deflateでdeflate圧縮するとか、CSSやJSファイルのHTTPレスポンスヘッダにLast-ModifiedやEtagを追加しておいて、ブラウザがHTTPリクエストヘッダにIf-Modified-SinceやIf-None-Matchを付加するようにし、コンテンツが変更されていなかったら304 Not Modifiedを返すという方法を取るかと思います。 しかし、HTTPサーバーはコンテンツの数だけ304 Not Modifiedを返さないといけないため、その分帯域を消費しますし、またCSSや画像などのパーツの304 Not Modifiedが返ってくるまで、そのパーツのレンダリングが行えないという問題があります（つまり体感速度に影響します）。 今回紹介するのはExpiresヘッダやCache-Control: max-age=31536000を
Apache module mod_rewrite
URL を操作するためのスイス製のアーミーナイフ、mod_rewrite へようこそ! このモジュールは、（正規表現パーサに基づく）ルールベースの 書き換えエンジンを使い、要求された URL を適宜書き換えます。 サポートするルールの数、および各ルールを適用する際のルール条件 の数に制限はなく、本当にフレキシブルでかつパワフルな URL 操作 メカニズムを提供します。この URL 操作に先立ち、次のようにいろいろな 評価を行なうことができます。たとえばサーバ変数、環境変数、HTTP ヘッダ、 タイムスタンプ、さらに外部データベースの検索結果までを評価の対象として、 各種のフォーマットを使った粒度の高い URL マッチングを実現できます。 このモジュールは、サーバ単位のコンテキスト (httpd.conf) およびディレクトリ単位のコンテキスト (.htaccess) において (PATH-
Apache URL Rewriting Guide
his document は http://www.apache.org/docs/mod/mod_rewrite.html にある Apache Group によるオリジナルの mod_rewrite マニュアルを補足するものです。ウェブマスターが普段、実際に直面している典型的な URL-based の問題を、mod_rewrite でどのように解決するかを記述しています。URL の rewriting ruleset を設定することによってそれぞれの問題を解決する方法を詳述してあります。 Table Of Contents はじめに 解決策 URL レイアウト Canonical URLs Canonical Hostnames DocumentRoot の移動 ディレクトリのスラッシュの解決 均一な URL 配置をした ウェブ・クラスタ 異なるウェブサーバへのホーム・ディレクトリの移
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
