web-dev-qa-db-ja.com

https：//[email protected]/xからhttps://example.com/x（htaccess）にリダイレクトする方法は？

何らかの理由でhttps://[email protected]/xやhttps://example.com/xなどの重複したURLが検索エンジンにあるという奇妙な問題があります

hi@を介して、最初の（つまりhi@を使用して）2番目のURL（つまり.htaccessを使用せずに）に301リダイレクトしたいのですが。

以下のようなコードを試しましたが、機能しません（その.htaccessファイルにある他のリダイレクトルールは機能します）。何か案は？

<IfModule mod_rewrite.c>
<IfModule mod_negotiation.c>
    Options -MultiViews
</IfModule>

RewriteEngine On

RewriteCond %{HTTP_Host} ^www\.(.*)$ [NC]
RewriteRule ^(.*)$ http://%1/$1 [R=301,L]

# Redirect Trailing Slashes If Not A Folder...
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)/$ /$1 [L,R=301]    

RewriteCond %{HTTP_Host} hi@example\.com$ [NC]
RewriteRule ^(.*)$ https://example.com/$1 [L,R=301]

</IfModule>
htaccessredirects301-redirectmod-rewrite
4
user6122500

@Stephenがコメントで示唆したように、hiは、username:passwordがURLの一部として指定されている場合のsername部分です（ RFC 1738 を参照）基本的なHTTP認証。

その場合は、検索エンジンに取得されるべきではありません

これは、他のサイトがこの形式のURLに（悪意を持って）リンクされているかどうかによって異なります。

hi@は実際にはHost: HTTP要求ヘッダーの一部として送信されないため、Apache HTTP_Hostの.htaccessサーバー変数と一致させることはできません。準拠ユーザーエージェントは、これをURLから取り除き、リクエストを行う前に、この情報を使用してbase64エンコードAuthorization:ヘッダーを作成します。

HTTP認証を使用していない場合、Authorization HTTP要求ヘッダーにsomethingを含む要求を潜在的にリダイレクト/ブロックできます。たとえば、.htaccessファイルの（末尾ではなく）次の上部を試すことができます。

RewriteCond %{HTTP:Authorization} !^$
RewriteRule (.*) https://example.com/$1 [R=301,L]

リダイレクトループを回避するために、2番目のリクエストでAuthorizationヘッダーを再度送信しないことにユーザーエージェントが依存しているため、これは少し危険です。この場合、「実際のユーザー」にとっては問題になりませんが、とにかく「ログイン」してはいけません。 Googlebotには、ログイン資格情報を差し引いたURLが表示されます（リダイレクトループが発生し、実際のコンテンツが実際に表示されない可能性がありますが、コンテンツの重複の問題は回避されます）。サイトでHTTP認証を本当に使用している場合、ユーザーが「ログイン」している場合、これは確かにリダイレクトループになります。

または、そのようなリクエストに対して410 Goneを代わりに提供します（とにかくこれらのURLから多くのSEO値を得ているとは思わないでしょう）：

RewriteCond %{HTTP:Authorization} !^$
RewriteRule ^ - [G]

UPDATE：@StephenOstermillerがコメントで示唆したように、技術的に正しい応答はおそらく代わりに401 Unauthorizedを返すことです。これには、ユーザーがログアウトするという追加の利点があります（実際にログインしている場合）。したがって、Authorizationヘッダーは後続のリクエストで送信されません。また、GoogleはSERPで4xx応答を返すべきではありません。たとえば、上記と同様：

RewriteCond %{HTTP:Authorization} !^$
RewriteRule ^ - [R=401]

最近のブラウザは、セキュリティ上の理由からリクエストを行う前にこの情報を完全に削除する傾向があるように見えるため、こうしたリンクが実際のユーザーに影響を与える可能性は低いことに注意してください。表示URLから削除され、Authorizationヘッダーは実際には送信されません。これはかなり以前にIEから削除されたようです。また、Chrome 64（およびOpera）での私のテストにも当てはまるようです。次の Chromeバグレポート はこれをバックアップし、この機能が削除されたことを示唆しています-バグレポートは「WontFix」のステータスで閉じられます。

次のServerFaultの質問では、このURL形式が「機能する」かどうかについて多くの議論があります（奇妙なことに、一部のユーザーは、これがChromeで機能すると述べています。

UPDATE：RFC 3986 （更新 RFC 1738 -上記リンク）は以前廃止予定であったことに注意してくださいURLでの「username：password」の使用

Userinfoフィールドでの「user：password」形式の使用は非推奨です。

3
MrWhite