web-dev-qa-db-fra.com

Pourquoi 301 redirige-t-il le délai d'attente avec HTTPS même s'il fonctionne avec HTTP?

Grâce à mon registraire de domaine, j'ai configuré un domaine, essayme.co.uk, à transférer automatiquement vers https://google.com .

Si je vais à http://essayme.co.uk cela fonctionne comme prévu et me redirige vers 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

Cependant, si je vais à https://essayme.co.uk , il se bloque et expire.

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

Que se passe-t-il dans le second cas?

(et, si possible, comment puis-je faire en sorte que la redirection fonctionne avec https?)

Problème de fond/clarification:

Je n'ai pas de certificat SSL pour le domaine essayme.co.uk ci-dessus, mais c'est le cas pour mon domaine actif (appelons-le mon sitewebsite.com), et je voyais exactement le même problème sur ce domaine (d'où la raison pour laquelle j'ai m essayant de déboguer le problème). Malheureusement, je ne peux pas expérimenter avec le domaine live (car il est live) et je voudrais éviter de devoir acheter un deuxième certificat pour essayme.co.uk uniquement pour le débogage (sauf en cas d'absolue nécessité).

Le problème que je voyais:

J'ai également essayé de le transférer à http://www.otherwebsite.com à titre expérimental (c'est-à-dire de le transférer à un autre site qui n'utilise pas le protocole SSL), mais le résultat était le même:

J'ai donc mis en place essayme.co.uk comme une expérience pour essayer de comprendre pourquoi cela ne fonctionne pas.

redirectshttpsdns
3
Tom G

http://example.com/something et https://example.com/something sont des adresses URI distinctes. Par conséquent, ils identifient différentes ressources. Bien qu'il soit courant de servir la même page sur un site Web à la fois pour http:// et https://, ce n'est en aucun cas obligatoire.

(En fait, je pense généralement qu'il est préférable de renvoyer 404 sur http:// URI qui serait un contenu sensible sur https:// pendant le temps de développement, au lieu d'utiliser des redirections automatiques de http:// vers https:// comme certains le font, afin de pouvoir détecter mauvais liens et connexions initiales non sécurisées , mais c'est un problème différent.)

Il n'y a aucune raison pour qu'une redirection de http://example.com/ vers https://something-else.example/ s'applique également à https://example.com/. Ce sont des URI distincts en ce qui concerne votre navigateur.

Puisque vous dites qu'aucun serveur HTTPS n'écoute sur le port 443 du domaine à partir duquel vous essayez de faire cette redirection https://, rien ne se passera.

De plus, si vous souhaitiez une redirection (ou toute autre forme de réponse) à partir de ce serveur HTTPS, vous devez également disposer d'un certificat valide. (De nombreuses autorités de certification émettent des certs avec deux noms alternatifs de sujet, pour example.com et www.example.com, mais toutes ne le font pas gratuitement.)

En tant que nœud latéral, lorsque vous testez des redirections, nous suggérons d'utiliser 302 au lieu de 301, car 301 seront souvent mis en cache par votre navigateur. Par conséquent, les modifications que vous avez apportées à la configuration ne sont pas toujours appliquées dans ton navigateur.

2
Bruno