WordPressでは、HTTPSにルーティングするために.htaccessファイルを編集する2つの異なる手法を見ました。これらの長所と短所は何ですか。
オプション#1
RewriteEngine On
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ https://www.example.com/$1 [R,L]
Www.example.comに移動すると、このソリューションはステータス302を返し、トラフィックを https://www.example.com にルーティングします。
ここで を参照してください 。
オプション#2
# Force HTTPS
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_Host}%{REQUEST_URI} [R=301,L]
私はこの解決策がステータス301を返すと信じています。オプション#1が機能するように見えるので、私はテストしていません。
ここで を参照してください 。
どちらかの方法を適用する前に、これが私の.htaccessファイルの関連ブロックです。
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{HTTPS} =on
RewriteRule .* - [E=W3TC_SSL:_ssl]
RewriteCond %{SERVER_PORT} =443
RewriteRule .* - [E=W3TC_SSL:_ssl]
RewriteCond %{HTTP:Accept-Encoding} gzip
RewriteRule .* - [E=W3TC_ENC:_gzip]
RewriteCond %{HTTP_COOKIE} w3tc_preview [NC]
RewriteRule .* - [E=W3TC_PREVIEW:_preview]
RewriteCond %{REQUEST_METHOD} !=POST
RewriteCond %{QUERY_STRING} =""
RewriteCond %{REQUEST_URI} \/$
RewriteCond %{HTTP_COOKIE} !(comment_author|wp\-postpass|w3tc_logged_out|wordpress_logged_in|wptouch_switch_toggle) [NC]
RewriteCond "%{DOCUMENT_ROOT}/wp-content/cache/page_enhanced/%{HTTP_Host}/%{REQUEST_URI}/_index%{ENV:W3TC_SSL}%{ENV:W3TC_PREVIEW}.html%{ENV:W3TC_ENC}" -f
RewriteRule .* "/wp-content/cache/page_enhanced/%{HTTP_Host}/%{REQUEST_URI}/_index%{ENV:W3TC_SSL}%{ENV:W3TC_PREVIEW}.html%{ENV:W3TC_ENC}" [L]
</IfModule>
どちらの解決策でも、RewriteBase /
の直後にRewriteCond
とRewriteRule
のエントリを追加するのは正しいですか。
.htaccess
/mod_rewriteディレクティブの違いは、通常、サーバー設定の違い(WordPressとは無関係)およびそれらが使用されている場所の違いによるものです。ワンサイズがすべてに収まるようなものはありません。 (たとえば、SSLプロキシの背後にいる場合、上記のリダイレクトは機能しない可能性があります。)ただし、ほとんどの場合と同じように、同じことを実行する方法が異なることがよくあります。だから、あなたはそれが完璧に動作するためにそれを1つの特定の方法で行う必要はありません。
オプション#1
RewriteCond %{SERVER_PORT} 80 RewriteRule ^(.*)$ https://www.example.com/$1 [R,L]
デフォルトでは、HTTPはポート80で動作します。これは、これがチェックするものです。ただし、HTTPを別のポートで機能するように設定することもできます。その場合、これは失敗します。
あなたが言ったように、これは302(一時的)リダイレクトです。 (R
name__フラグで明示的に状況コードを含めない場合のデフォルトの状況。)testing以外の場合、HTTPからHTTPSへのリダイレクトは永続的なものと見なされます。それで、あなたは通常これが301であると予想するでしょう、すなわち。 R=301
。 301個のリダイレクトはブラウザによってキャッシュされ、検索エンジンによる恒久的な変更と見なされます。
^(.*)$
- 厳密に言うと、開始と終了のアンカーです。 ^
と$
はまったく不要です。 ^(.*)$
は(.*)
と同じです。ただし、前者の方が読みやすいというユーザーもいます。だからあなたが好むものは何でも。これは単にURLパス全体を取得して、後でreplacementで使用される$1
バックリファレンスに保存するだけです。
https://www.example.com/$1
- 置換の中にcanonicalホスト名をハードコーディングすることは間違いなくもっと信頼できます。自分のサイトで使用するためにこのコードを他の人に渡すと、エラーに対するマージンが少なくなります。サーバ管理者はしばしばこれがあなたがいつもそれをするべき方法であると主張します(私は必ずしも同意しませんが - 私はサーバ管理者ではありませんが)。 (特に、複数のドメインがあり、wwwとwww以外のホスト名が異なる場合)ハードコーディングは...ハードコーディングです。それで、それはあまり移植性がありません。
このディレクティブは.htaccess
(またはdirectoryコンテキスト)でのみ使用されるべきです。これをサーバーの設定で直接使用した場合(そうではありません)、リダイレクトされたURLに二重スラッシュ(//
)が表示されます。
オプション#2
RewriteCond %{HTTPS} off RewriteRule (.*) https://%{HTTP_Host}%{REQUEST_URI} [R=301,L]
HTTPS
name__は、Apacheによって設定されたサーバー変数です。これはoff
name__またはon
name__のいずれかであり、HTTP(および/またはHTTPS)が提供されているポートに関係なく機能します。 SERVER_PORT
をチェックするよりも間違いなく読みやすいです。しかし、HTTPS
name__はApache 1.3では利用できません(それは実際には問題にならないはずですが!)ほとんどのサーバーでは、%{SERVER_PORT} 80
と%{HTTPS} off
のチェックに違いはありません。
R=301
- 良い、301(恒久的)リダイレクトです。これは通常あなたが望むものです。
(.*)
- 不要なアンカーはありません(上記参照)。ただし、substitutionでは$1
後方参照は使用されていないため(%{REQUEST_URI}
が代わりに使用されるため)、不要な(軽微な)オーバーヘッドであり、削除する必要があります。これは.*
または単に^
と書くべきです。
https://%{HTTP_Host}%{REQUEST_URI}
- HTTP_Host
サーバー変数は、リクエストに含まれるホスト名を保持します。あなたのサイトが複数のドメインを介してアクセス可能であるならば、これはどんなドメインが要求されていても保持します。あなたのSSL証明書がこれらのドメインの1つだけをカバーしているなら、これは壊れます。これはwww対www以外の違いを正規化するものでもありません - 潜在的な二重リダイレクトを避けるためにbeforeこのディレクティブを実行する必要があります。 ).
substitutionで%{REQUEST_URI}
を使用しているため、この規則は変更することなくサーバー設定ファイルまたは.htaccess
ファイルで使用できます。
オプション#3
RewriteCond %{HTTPS} off RewriteRule ^ https://www.example.com%{REQUEST_URI} [R=301,L]
どちらの解決策でも、
RewriteBase /
の直後にRewriteCond
name__とRewriteRule
name__のエントリを追加するのは正しいですか。
はい、それはそれを置くための論理的な場所です。 (ただし、RewriteEngine
name__ディレクティブ - technicallyの前であっても、それよりも先に進む可能性があります。問題ありません。)