it-swarm.com.de

Warum leitet 301 das Timeout mit HTTPS um, obwohl es mit HTTP funktioniert?

Über meinen Domain-Registrar habe ich eine Domain eingerichtet, essayme.co.uk, um automatisch an https://google.com weiterzuleiten.

Wenn ich zu http://essayme.co.uk gehe, funktioniert es wie erwartet und leitet mich zu https weiter: //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

Wenn ich jedoch zu https://essayme.co.uk gehe, friert es einfach ein und läuft aus.

$curl -i https://essayme.co.uk
curl: (7) Failed connect to essayme.co.uk:443; Operation timed out

Was passiert im zweiten Fall?

(Und, wenn möglich, wie kann ich die Weiterleitung für https aktivieren?)


Problemhintergrund/Klärung:

Ich habe kein SSL-Zertifikat für die oben genannte essayme.co.uk-Domain, aber für meine Live-Domain (nennen wir es mywebsite.com). Auf dieser Domain ist genau dasselbe Problem aufgetreten (daher: warum habe ich?). Ich versuche das Problem zu debuggen. Leider kann ich nicht mit der Live-Domain experimentieren (da sie live ist), und ich möchte vermeiden, ein zweites Zertifikat für essayme.co.uk nur zum Debuggen kaufen zu müssen (sofern dies nicht unbedingt erforderlich ist).

Das Problem, das ich sah:

Ich habe auch versucht, es als Experiment an http://www.otherwebsite.com weiterzuleiten (dh an eine andere Site, die kein SSL verwendet), aber Das Ergebnis war das gleiche:

Deshalb habe ich essayme.co.uk als Experiment eingerichtet, um zu verstehen, warum es nicht funktioniert.

3
Tom G

http://example.com/something und https://example.com/something sind unterschiedliche URIs. Daher identifizieren sie unterschiedliche Ressourcen. Es ist zwar gängige Praxis, auf einer Website dieselbe Seite für http:// und https:// bereitzustellen, dies ist jedoch keineswegs obligatorisch.

(Tatsächlich denke ich im Allgemeinen, dass es besser ist, 404 auf http://-URIs zurückzugeben, die während der Entwicklungszeit sensible Inhalte auf https:// darstellen, anstatt automatische Weiterleitungen von http:// zu https:// zu verwenden, wie dies einige tun, um in der Lage zu sein zu erkennen, schlechte links und unsichere anfangsverbindungen , aber das ist ein anderes problem.)

Es gibt keinen Grund, warum eine Umleitung von http://example.com/ zu https://something-else.example/ auch für https://example.com/ gelten sollte. Für Ihren Browser sind dies unterschiedliche URIs.

Da Sie sagen, dass auf Port 443 der Domäne, von der aus Sie diese https://-Umleitung durchführen möchten, kein HTTPS-Server empfangsbereit ist, wird nichts passieren.

Wenn Sie eine Umleitung (oder eine andere Form der Antwort) von diesem HTTPS-Server wünschen, benötigen Sie außerdem ein gültiges Zertifikat dafür. (Viele Zertifizierungsstellen stellen Zertifikate mit zwei alternativen Antragstellernamen für example.com und www.example.com aus, aber nicht alle tun dies kostenlos.)

Als Nebenknoten würde ich beim Experimentieren mit Umleitungen die Verwendung von 302 anstelle von 301 vorschlagen, da 301 häufig von Ihrem Browser zwischengespeichert wird, sodass die Änderungen, die Sie in der Konfiguration vorgenommen haben, möglicherweise nicht immer übernommen werden dein Browser.

2
Bruno