末尾のスラッシュと疑問符を削除します

Jun 10 2020

簡単にまとめると、http：//および任意のwwwを正常にリダイレクトする次の.htaccessファイルを実装しました。https：//への検索

私の問題-redirectruleが適用された後、末尾に//？たとえば：http://www.example.com になります https://example.com//？

別のページの別の例： http://www.example.com/test になります https://example.com//test？

したがって、さらに明確にするために。httpからhttpsへのリダイレクトには満足していますが、最後のスラッシュが1つだけ必要で、URLには他に何も必要ありません。このような他の例を見つけることができないので、ヘルプやアドバイスは素晴らしいでしょう。

必須-http://www.example.com になる https://example.com/

これが私の.htaccessコードです...

RewriteEngine On
RewriteCond %{SERVER_PORT} !=443
RewriteRule ^(.*)$ https://settlerslodge.co.uk/$1 [R,L]

回答

Pandurang Jun 10 2020 at 22:00

以下の書き換えルールを使用してテストします。

RewriteEngine On
RewriteCond %{SERVER_PORT} !^443$ RewriteRule ^/?(.+)/?$  https://%{HTTP_HOST}/$1 [L,R]

arkascha Jun 11 2020 at 00:21

これはクリーンなセットアップになります。

RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^/?(.+)/?$ https://example.com/$1 [R=301,QSD,END]

すべてが正しく設定されていることを確認したら、302の一時的なリダイレクトから始めて、後でそれを301の永続的なリダイレクトに変更することをお勧めします。それは物事を試している間キャッシュの問題を防ぎます...

上記のルールを使用して内部サーバーエラー（httpステータス500）を受け取った場合は、非常に古いバージョンのApachehttpサーバーを操作している可能性があります。[END]その場合、httpサーバーのエラーログファイルにサポートされていないフラグへの明確なヒントが表示されます。アップグレードを試みるか、古い[L]フラグを使用することができます。セットアップによって少し異なりますが、この状況でもおそらく同じように機能します。

この実装は、httpサーバーのホスト構成または分散構成ファイル（「.htaccess」ファイル）内でも同様に機能します。明らかに、書き換えモジュールはhttpサーバー内にロードされ、httpホストで有効にする必要があります。分散構成ファイルを使用する場合は、その解釈がホスト構成でまったく有効になっていて、ホストのDOCUMENT_ROOTフォルダーにあることに注意する必要があります。

また、一般的な注意事項：分散構成ファイル（ ".htaccess"）を使用するのではなく、常にそのようなルールをhttpサーバーのホスト構成に配置することをお勧めします。これらの分散構成ファイルは複雑さを増し、予期しない動作の原因となることが多く、デバッグが難しく、httpサーバーの速度が大幅に低下します。これらは、実際のhttpサーバーのホスト構成にアクセスできない状況（読み取り：非常に安価なサービスプロバイダー）または独自のルールの作成を要求するアプリケーション（これは明らかなセキュリティの悪夢です）の最後のオプションとしてのみ提供されます。