htaccessに配置されるルールの順序は重要ですか?


9

これが単純な「はい」または「いいえ」の答えであることを願っています(理由を明記してください)

Q1:ルールがhtaccessに配置される順序は重要ですか? それらは完全に分離されたアイテムなので、例えば

Q2:はいの場合、正しい注文を適用していますか? htaccesエンジンを高速化し、不必要なルールで過負荷にしないために?

Q3:ここで無効にする/追加するためのヒントは、大歓迎です+1!


# DirectoryIndex index.php /index.php
AddDefaultCharset UTF-8
RewriteEngine on
# Options All
# Options +FollowSymLinks
# Options +FollowSymLinks -Indexes -ExecCGI
# RewriteBase /

#####################################################

<IfModule mod_headers.c>
    ExpiresActive On
    ExpiresDefault M172800
    Header unset ETag
    FileETag None
    Header unset Pragma

    ##### STATIC FILES
    <FilesMatch "\\.(ico|jpg|png|gif|svg|swf|css|js|fon|ttf|eot|xml|pdf|flv)$">
        ExpiresDefault M1209600
        Header set Cache-Control "public, max-age=1209600"
    </FilesMatch>

    ##### DYNAMIC PAGES
    <FilesMatch "\\.(php)$">
        ExpiresDefault M604800
        Header set Cache-Control "public, max-age=604800"
    </FilesMatch>
</IfModule>

#####################################################

#  /page123 and /page123/ will all go to /page123.php
RewriteRule ^(.+)/$  /$1 [R=301,L]
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME}\.php -f
RewriteRule ^(.*)$ $1.php

####################################################

# NO WWW   http://www. becomes always http://
RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
RewriteRule ^(.*)$ http://%1/$1 [R=301,L]

##############################################################
# add own extensions that will be interpreted as php
AddType application/x-httpd-php .php
AddType image/svg+xml svg svgz
AddType text/css css
AddType text/javascript js
AddEncoding gzip svgz

##############################################################

ErrorDocument 500 /
ErrorDocument 404 /

回答:


10

まあ、.htaccessファイルは通常のApache構成ファイルと同じ形式を使用するため、同じルールが適用されます。

ほとんどの設定は順序に依存しませんが、一部は依存します-設定に依存します。

RewriteRuleそしてRewriteCond例えばので、その場合には答えはYESで、順番に敏感です。

例を見る

http://wiki.apache.org/httpd/RewriteRule

これらが評価される順序の説明については。


4

それは問題である。RewriteRuleのドキュメントから引用:

これらのルールが定義される順序は重要です-これは、実行時に適用される順序です。


1
mod_rewrite内では、重要です-はい。ただし、OPは特にmod_rewriteに対応しているわけではなく、OPの.htaccessファイルには他のモジュールからの他の多くのディレクティブがあります。つまり、さまざまなモジュール(およびさまざまなコンテナ)からのディレクティブは、構成ファイルでの明白な順序に関係なく、独立して事前定義された順序で実行されます。
MrWhite

1

たとえば、<files>vs の順序が<Rewrite>パフォーマンスにどのように影響するかについては説明できません。私はそれを自分で見つけようとしています。これに関する情報を見つけることができなかったので、おそらくそれは問題ではありませんか?

しかし、私は間のことを指摘したいと思いRewriteRedirect(およびRedirectMatch)、実行の順序がありそれは、人々が期待するかもしれないものが多いのですが...、列挙された順にならない
具体的には、mod_rewriteおよびmod_aliasモジュールは/処理されindependantly実行、およびにその注文。

  1. すべてのmod_rewriteディレクティブ(Rewrite)が(リストされている順に)実行されます。
  2. THENすべてmod_aliasディレクティブは、(RedirectRedirectMatch)順序で実行されている彼らは、ファイルにリストされています。

したがって、aがRedirect続行された場合でも、すべての書き換えが処理された後でRewriteのみリダイレクトが処理されます。

リダイレクトと書き換えの両方がある場合にファイルを「読み取り可能」に保つ1つの方法は、mod_aliasモジュールをまったく使用しないことです。代わりに、のみを使用してくださいmod_rewrite。[R]フラグによる書き換えは、本質的にそれを書き換えに変えます。
このウェブマスターの回答は、その方法を示しています。

これで、すべてのディレクティブがファイルに表示される順序で実行されるため、実行順序について厄介な驚きや混乱はありません。また、あなたは可能性があり、物理的にすべて移転Redirectし、RedirectMatch彼らは後まで実行されないことを自分自身を思い出させるように、ファイルの「下」にディレクティブをRewriteとにかくです。

この時点で啓発されたいくつかの優れたStackExchange回答を次に示します。

残りについては、例えば、files前と後rewriteの間にパフォーマンスに関する情報を見つけることができませんでした。私が見つけた唯一のパフォーマンスベースのアドバイスは、サーバー構成ファイルにアクセスできる場合、.htaccessファイルから構成ファイルにできるだけ移動、.htaccessファイル完全に無効にする(または特定のディレクトリを指定する)ことです。 .htaccessファイル読み取る必要があります)。

ロジックでは、構成ファイルに配置されたルールは一度だけ読み取る必要があります。htaccessの処理がオンになっている場合、そのためにすべての要求、すべてのサーバーのディレクトリ(時または要求されたディレクトリよりも高い)は、それらが存在するかどうか、可能性のhtaccessファイルを検索する必要があります。そして、彼らがそうするならば、一人一人が新たに読まれなければなりません。


-1

私は同じ懸念事項を投稿していますが、これはサーバー管理サイトの視点であり、Apacheサーバーの設定変更後にApacheを再起動できます。

これまでのところ、私が受け取った最良の応答は、ファイル関連のディレクティブを最初にリストすることです。

これは、Apacheがディレクトリを管理する必要性と、各ディレクトリのhtaccess命令に関連して理にかなっています。

したがって、最初にファイル関連のディレクティブをリストし、次に明らかなブロックをリストして、Apache htaccessプロセスを明白な順に終了します。

リクエストを最適化するための可能な解決策:-リクエストURL関連の修正-ディレクトリ関連の制限-インデックス関連の制限-ファイル関連の制限-プロキシ制限<-kill all-空のユーザーエージェント<-kill all ...リストは無限の楽しみです

ディレクティブのシーケンスに関する私の懸念。たとえば、RewriteCondsの前にIndex、file、Headerディレクティブを設定する必要がありますか?


脚注:RewriteRuleパターン置換[フラグ]は、この明白なアプリケーション処理の質問には答えません!
テストベンチ2015
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.