web-dev-qa-db-ja.com

httpd.confではRewriteCondは無視されます

簡単に言うと、これはhtaccessで機能します。

RewriteEngine on

RewriteCond %{SCRIPT_FILENAME} !-f 
RewriteCond %{SCRIPT_FILENAME} !-d 

RewriteRule ^([^/]+)/?$ https://example.net?u=$1 [L,NC,R=301]

しかし、httpd.confに移動しても何も起こりません。 directoryディレクティブを試しましたが、それでも違いはありません。

以下のhttpd.confのテストが影響を与えるため、リダイレクトされますが、すべてのページにリダイレクトされます。つまり、条件は無視されます。

RewriteEngine on

RewriteCond %{SCRIPT_FILENAME} !-f 
RewriteCond %{SCRIPT_FILENAME} !-d 

RewriteRule ^(.*)$ https://example.net?u=$1 [L,NC,R=301]
mod-rewriteapache2
4
Guesser
RewriteRule ^([^/]+)/?$ https://example.net?u=$1 [L,NC,R=301]

しかし、httpd.confに移動しても何も起こりません。

serverコンテキストでは、RewriteRulepatternは決して一致しません。サーバーコンテキストでは、URLパスはルート相対であり、スラッシュで始まります。 .htaccessでは、URLパスはディレクトリプレフィックスよりも小さいため、スラッシュで始まることはありません。

私はディレクトリディレクティブを試しましたが、それも違いはありません。

正しいディレクトリパスを含めれば、それはうまくいくはずです。 （そしてApacheを再起動しました。）ただし、書き換えエンジンを有効にする.htaccessファイルがまだある場合は、これにより<Directory>コンテナ内のサーバーディレクティブが上書きされるため、<Directory>ディレクティブはまだ何もしていません。

以下のhttpd.confのテストが影響を与えるため、リダイレクトされますが、すべてのページにリダイレクトされます。つまり、条件は無視されます。

RewriteEngine on

RewriteCond %{SCRIPT_FILENAME} !-f 
:

serverコンテキストでは、リクエストはまだファイルシステムにマップされていないため、SCRIPT_FILENAME（またはREQUEST_FILENAME）にはまだ完全なファイルシステムパスが含まれていません（単にURL-path）であるため、この条件は常にtrueと評価されます（テストされる「URL-path」は物理ファイルではありません-つまりおそらく正しいです）。

最終的な値を決定するには、代わりに先読みを使用する必要があります。すなわち。 %{LA-U:REQUEST_FILENAME}。

したがって、server（またはvirtualhost）コンテキストでは、代わりに次を使用する必要があります。

RewriteEngine on

RewriteCond %{LA-U:REQUEST_FILENAME} !-f 
RewriteCond %{LA-U:REQUEST_FILENAME} !-d 

RewriteRule ^/([^/]+)/?$ https://example.net?u=$1 [L,R=301]

RewriteRulepatternのスラッシュプレフィックスに注意してください。

NCフラグはここでは不要です。

4
DocRoot