ドメインレジストラーを通じて、essayme.co.ukというドメインを設定して、自動的に https://google.com に転送します。
http://essayme.co.uk に移動すると、期待どおりに動作し、 https://google.com にリダイレクトされます。
$curl -i http://essayme.co.uk
HTTP/1.1 301 Moved Permanently
Cache-Control: max-age=900
Content-Type: text/html
Location: https://google.com
Server: Microsoft-IIS/7.5
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Date: Sat, 07 Jun 2014 11:14:16 GMT
Content-Length: 0
Age: 0
Connection: keep-alive
ただし、 https://essayme.co.uk に移動すると、フリーズしてタイムアウトします。
$curl -i https://essayme.co.uk
curl: (7) Failed connect to essayme.co.uk:443; Operation timed out
2番目のケースで何が起こっていますか?
(そして、可能であれば、リダイレクトをhttpsで機能させるにはどうすればよいですか?)
問題の背景/説明:
上記のessayme.co.ukドメインのSSL証明書はありませんが、ライブドメイン(mywebsite.comと呼びます)のSSL証明書はありません。このドメインでもまったく同じ問題が発生していました(そのため、 m問題をデバッグしようとしています)。残念ながら、ライブドメイン(ライブであるため)を試すことはできません。デバッグのためだけにessayme.co.ukの2つ目の証明書を購入する必要はありません(絶対に必要でない限り)。
私が見ていた問題:
また、実験として http://www.otherwebsite.com に転送しようとしました(つまり、SSLを使用しない別のサイトに転送しました)が、結果は同じでした:
それで、私はessayme.co.ukを実験として設定し、なぜ機能しないのかを試して理解しました。
http://example.com/something
とhttps://example.com/something
は別個のURIです。したがって、異なるリソースを識別します。 http://
とhttps://
の両方にWebサイトの同じページを提供することは一般的な慣行ですが、決して必須ではありません。
(実際、検出するために、いくつかのようにhttp://
からhttps://
への自動リダイレクトを使用するのではなく、開発時にhttp://
の機密コンテンツであるhttps://
URIで404を返す方が一般的には良いと思います 悪いリンクと安全でない初期接続 、しかしそれは別の問題です。)
http://example.com/
からhttps://something-else.example/
へのリダイレクトがhttps://example.com/
にも適用される理由はありません。ブラウザに関する限り、これらは別個のURIです。
このhttps://
リダイレクトを行おうとしているドメインのポート443でリッスンしているHTTPSサーバーがないと言っているので、何も起こりません。
さらに、そのHTTPSサーバーからのリダイレクト(または他の形式の応答)が必要な場合は、そのための有効な証明書も必要になります。 (多くのCAは、example.com
とwww.example.com
の2つのサブジェクトの別名を持つ証明書を発行しますが、すべてが無料で発行するわけではありません。)
サイドノードとして、リダイレクトを試すときは、301の代わりに302を使用することをお勧めします。これは、301がブラウザによってキャッシュされることが多いため、設定で行った変更が常に適用されるとは限らないためですブラウザ。