【一発理解】mod_rewriteのURL転送が動かず迷ったらこれを確認(パスのスラッシュ)

mod_rewriteを利用してURL転送を行おうと思った際に、
「何故かうまく動かない」そんな経験は誰しもあるのではないでしょうか。
これをみれば「あーなるほど」となる理解度が高まる転送例をご紹介します。
ここでは「RewriteCond %{REQUEST_URI}」とRewriteRuleによる、
ディレクトリ判定の違いについてご紹介します。

URL転送が動かず迷ったらこれを確認

mod_rewriteのURL転送が動かない時のチェックポイントを、
ご紹介するよりは以下の転送例を見て頂いた方が早いと思います。

http://one-solution.trce.info/.htaccess

この転送パターンを見て何か疑問を感じないでしょうか。

以下の点です。

RewriteCond %{REQUEST_URI} ^/$
RewriteRule ^$ http://redirect.trce.info/one-solution/ [R=302,L]

RewriteCond では、URL（%{REQUEST_URI}）と「/」を比較しています。

かたや、

RewriteRule では、要求パスを「^$」 ですから「空文字」と比較しています。

実際に転送の挙動を確認してみます。

http://one-solution.trce.info/　へアクセスすると、
http://redirect.trce.info/one-solution/　へ転送されるのが確認できると思います。

ちゃんと転送されます^^

mod_rewriteの記述の大前提

サブディレクトリであってもこの法則は同じです。

「http://one-solution.trce.info/dir/」へのアクセス要求は、
それぞれ、以下の値との比較が行われています。

• RewriteCond ：　/dir/
• RewriteRule ：　dir/

※dir/へのアクセスは　http://one-solution.trce.info/　には、
転送設定を行っていませんので確認できません。

さて、このスラッシュの有無を意識して、
URL転送の記述を行っていましたか？

なんとなくRewriteRuleには「(.*)」として、全転送を指定してしまって、
RewriteCond側で%{REQUEST_URI}による条件判定としていることも多いでしょう。

記述の違いによる転送例

上記を踏まえて、それぞれ
RewriteCondによる判定と、RewriteRuleによる判定を行うと、
以下のように記述することができます。

パターン１

RewriteCond %{REQUEST_URI} ^/source(.*)/$
RewriteRule .* http://redirect.trce.info/one-solution-s1/dist%1/ [R=302,L]

と書くよりは、

パターン２

以下のように１行で書いた方がシンプルだったりします。

転送先が増えてくれば、行数は倍の違いが出てきますし、
できるだけ、.htaccessは小さく保ちたいものです。

RewriteRule ^source(.*)/(.*) http://redirect.trce.info/one-solution-s2/dist$1/$2 [R=302,L]

パターン１確認環境

パターン１の例は以下で確認できます。

.htaccessでは以下のように定義しています。

http://one-solution-s1.trce.info/.htaccess

この場合それぞれ以下のように転送されることが確認できます。

パターン２確認環境

パターン２の例は以下で確認できます。

.htaccessでは以下のように定義しています。

http://one-solution-s2.trce.info/.htaccess

この場合それぞれ以下のように転送されることが確認できます。

どうでしょうか、非常に基本的な部分ではありますが、
いつも意識して記述していましたでしょうか。

呪文のように使われている(.*)ですが、
そもそもRewriteRule　のみの行で事足りることも多いと思います。

さいごに

様々な転送例は多くのサイトで紹介されていると思いますが、
細かなポイントはあまり紹介されていないというか、

これなら転送できますという１つの例が紹介されていることが大半の印象です。

でも、なんで転送ができるのか？という点や、
どうしてこの記述になるのか？といった点に言及されていないことが多くあります。

このポイントだけは押さえて、
あとは要求されるURLのパターンを組み立てれば済むはずです。

実はつまずくポイントの最初がこのスラッシュの有無による違いだと私は思います。

尚、こうしたmod_rewriteによる転送パターンは、
実際に検証をおこなって、挙動を確認しています。

以下ではなんとなく理解しているつもりのmod_rewriteによる転送で、
さまざまなパターンによる転送例をご紹介しています。

Apache,Apache Hadoop,Apache Subversion,Hadoop,HDFS,HBase,Hive,Mahout,Pigは、
Apache Software Foundationの米国およびその他の国における登録商標または商標です。

ApacheソフトウェアはApache Software License (原文)および
Apache License, 2.0 (原文)に基づきOpen Source Initiativeに承認されライセンスされています。

*本ページ内に記載されされた各社ブランド、サービス名、商標、登録商標については、
各社ブランドのロゴや商標等に関する帰属についてをご確認ください

最後までお読みいただきありがとうございました。

お勧めさせて頂きたい投稿です

• 【巧妙な仕組】Google+へAndroidの写真が勝手にアップロードされてしまう流れは設定ミスではない

• JetPackサイト統計データが消えた場合に復活する手順(してもらう)

• 【待望】WALLET ポイントがauID(au電話番号)間で相互にやりとりできるようになりました

• 禁断の機能がau公式解禁！WALLETポイントの現金化がついに開放。

• 何もしないと、auポイントが2014/05月分以降は携帯利用料から付与されなくなります

• au WALLET™カードはauを解約してもプリペイドとして使い続けられるが、有効期限には注意

• じぶん銀行が動いた！コンビニATM利用が無料・他行振込無料（回数制限なし）で使える

• 【旬】「白すぎる」と賛否両論？姫路城見るなら今秋がおすすめ！その理由は？｜castlehimeji.com

• Google+の投稿が勝手に自動でブログになっていくPluCialが便利



アイキャッチ画像に利用させて頂いております、各社ブランドのロゴやシンボルに関しては、
各社ブランドのロゴや商標等に関する帰属についてをご確認頂けますようお願い致します。

AdMax Promotion

ブログ記事のご紹介

すべて展開 | すべて省略

Rakuten Promotion

ページ

すべて展開 | すべて省略