En hébergement mutualisé OVH, on ne peut manifestement pas rediriger un
sous-domaine vers une URL en https (en mode ORT ou DNS expert).
Quels sont les registrars l'autorisant ?
Ce n'est pas une règle, on peut l'outrepasser (avec un seul certificat pour tout le monde, éventuellement sur *.domaine.tld, ou avec plusieurs domaines dans altCNname ou un truc comme ca).
C'est une limitation vraiment idiote, parce qu'avec la méthode HTTP UPGRADE tout échange pourrait se passer correctement, même avec une seule IP.
J'ai dû louper un épisode, parce que j'en suis resté à : la présentation du certificat par le serveur a lieu après l'établissement de la connexion TCP et avant l'envoi de toute requête HTTP, donc avant que le nom de domaine du site soit connu par le serveur.
La règle étant un certif ssl = une ip [...]
Ce n'est pas une règle, on peut l'outrepasser (avec un seul certificat
pour tout le monde, éventuellement sur *.domaine.tld, ou avec plusieurs
domaines dans altCNname ou un truc comme ca).
C'est une limitation vraiment idiote, parce qu'avec la méthode HTTP
UPGRADE tout échange pourrait se passer correctement, même avec une
seule IP.
J'ai dû louper un épisode, parce que j'en suis resté à : la présentation
du certificat par le serveur a lieu après l'établissement de la
connexion TCP et avant l'envoi de toute requête HTTP, donc avant que le
nom de domaine du site soit connu par le serveur.
Ce n'est pas une règle, on peut l'outrepasser (avec un seul certificat pour tout le monde, éventuellement sur *.domaine.tld, ou avec plusieurs domaines dans altCNname ou un truc comme ca).
C'est une limitation vraiment idiote, parce qu'avec la méthode HTTP UPGRADE tout échange pourrait se passer correctement, même avec une seule IP.
J'ai dû louper un épisode, parce que j'en suis resté à : la présentation du certificat par le serveur a lieu après l'établissement de la connexion TCP et avant l'envoi de toute requête HTTP, donc avant que le nom de domaine du site soit connu par le serveur.
Patrick Mevzek
J'ai dû louper un épisode, parce que j'en suis resté à : la présentation du certificat par le serveur a lieu après l'établissement de la connexion TCP et avant l'envoi de toute requête HTTP, donc avant que le nom de domaine du site soit connu par le serveur.
Cf la méthode HTTP qui va bien qui permet 1) de commencer un échange en HTTP, et donc notamment envoyer le bon Host: 2) puis passer en SSL.
Cf notamment §14.42 du RFC2616 (ok, UPGRADE n'est pas une méthode HTTP, désolé pour le raccourci)
D'où problème résolu. Maintenant la bonne question c'est : pourquoi ce n'est pas devenu le comportement par défaut, plutôt que de réserver TCP/443 pour le HTTPS ?
Tous les autres protocoles qui ont introduit une version sslisée sur un port à part, sont repassés sur le port par défaut avec négociation à la volée. En tout cas c'est la tendance. Cela n'a pas l'air d'être le cas pour HTTPS, pourtant c'est bien le web le plus gros consommateur d'IP.
A moins que ce ne soit un coup monté des partisans d'IPv6, allez savoir, il faut bien trouver un moyen de pression :-)
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
J'ai dû louper un épisode, parce que j'en suis resté à : la présentation
du certificat par le serveur a lieu après l'établissement de la
connexion TCP et avant l'envoi de toute requête HTTP, donc avant que le
nom de domaine du site soit connu par le serveur.
Cf la méthode HTTP qui va bien qui permet
1) de commencer un échange en HTTP, et donc notamment envoyer le bon Host:
2) puis passer en SSL.
Cf notamment §14.42 du RFC2616 (ok, UPGRADE n'est pas une méthode HTTP,
désolé pour le raccourci)
D'où problème résolu. Maintenant la bonne question c'est :
pourquoi ce n'est pas devenu le comportement par défaut, plutôt que de
réserver TCP/443 pour le HTTPS ?
Tous les autres protocoles qui ont introduit une version sslisée sur un
port à part, sont repassés sur le port par défaut avec négociation à
la volée. En tout cas c'est la tendance. Cela n'a pas l'air d'être le
cas pour HTTPS, pourtant c'est bien le web le plus gros consommateur d'IP.
A moins que ce ne soit un coup monté des partisans d'IPv6, allez savoir,
il faut bien trouver un moyen de pression :-)
--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
J'ai dû louper un épisode, parce que j'en suis resté à : la présentation du certificat par le serveur a lieu après l'établissement de la connexion TCP et avant l'envoi de toute requête HTTP, donc avant que le nom de domaine du site soit connu par le serveur.
Cf la méthode HTTP qui va bien qui permet 1) de commencer un échange en HTTP, et donc notamment envoyer le bon Host: 2) puis passer en SSL.
Cf notamment §14.42 du RFC2616 (ok, UPGRADE n'est pas une méthode HTTP, désolé pour le raccourci)
D'où problème résolu. Maintenant la bonne question c'est : pourquoi ce n'est pas devenu le comportement par défaut, plutôt que de réserver TCP/443 pour le HTTPS ?
Tous les autres protocoles qui ont introduit une version sslisée sur un port à part, sont repassés sur le port par défaut avec négociation à la volée. En tout cas c'est la tendance. Cela n'a pas l'air d'être le cas pour HTTPS, pourtant c'est bien le web le plus gros consommateur d'IP.
A moins que ce ne soit un coup monté des partisans d'IPv6, allez savoir, il faut bien trouver un moyen de pression :-)
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Pascal Hambourg
J'ai dû louper un épisode, parce que j'en suis resté à : la présentation du certificat par le serveur a lieu après l'établissement de la connexion TCP et avant l'envoi de toute requête HTTP, donc avant que le nom de domaine du site soit connu par le serveur.
Cf la méthode HTTP qui va bien qui permet 1) de commencer un échange en HTTP, et donc notamment envoyer le bon Host: 2) puis passer en SSL.
Cf notamment §14.42 du RFC2616 (ok, UPGRADE n'est pas une méthode HTTP, désolé pour le raccourci)
Dans ce paragraphe je lis : "The Upgrade header field only applies to switching application-layer protocols upon the existing transport-layer connection."
Or si je ne m'abuse TLS/SSL est une couche de transport, non ?
D'où problème résolu. Maintenant la bonne question c'est : pourquoi ce n'est pas devenu le comportement par défaut, plutôt que de réserver TCP/443 pour le HTTPS ?
Peut-être parce que ça ne plaît pas que la requête GET/POST/autre passe en clair, puisque transmise avant l'en-tête en question ?
J'ai dû louper un épisode, parce que j'en suis resté à : la présentation
du certificat par le serveur a lieu après l'établissement de la
connexion TCP et avant l'envoi de toute requête HTTP, donc avant que le
nom de domaine du site soit connu par le serveur.
Cf la méthode HTTP qui va bien qui permet
1) de commencer un échange en HTTP, et donc notamment envoyer le bon Host:
2) puis passer en SSL.
Cf notamment §14.42 du RFC2616 (ok, UPGRADE n'est pas une méthode HTTP,
désolé pour le raccourci)
Dans ce paragraphe je lis :
"The Upgrade header field only applies to switching application-layer
protocols upon the existing transport-layer connection."
Or si je ne m'abuse TLS/SSL est une couche de transport, non ?
D'où problème résolu. Maintenant la bonne question c'est :
pourquoi ce n'est pas devenu le comportement par défaut, plutôt que de
réserver TCP/443 pour le HTTPS ?
Peut-être parce que ça ne plaît pas que la requête GET/POST/autre passe
en clair, puisque transmise avant l'en-tête en question ?
J'ai dû louper un épisode, parce que j'en suis resté à : la présentation du certificat par le serveur a lieu après l'établissement de la connexion TCP et avant l'envoi de toute requête HTTP, donc avant que le nom de domaine du site soit connu par le serveur.
Cf la méthode HTTP qui va bien qui permet 1) de commencer un échange en HTTP, et donc notamment envoyer le bon Host: 2) puis passer en SSL.
Cf notamment §14.42 du RFC2616 (ok, UPGRADE n'est pas une méthode HTTP, désolé pour le raccourci)
Dans ce paragraphe je lis : "The Upgrade header field only applies to switching application-layer protocols upon the existing transport-layer connection."
Or si je ne m'abuse TLS/SSL est une couche de transport, non ?
D'où problème résolu. Maintenant la bonne question c'est : pourquoi ce n'est pas devenu le comportement par défaut, plutôt que de réserver TCP/443 pour le HTTPS ?
Peut-être parce que ça ne plaît pas que la requête GET/POST/autre passe en clair, puisque transmise avant l'en-tête en question ?
Patrick Mevzek
Cf la méthode HTTP qui va bien qui permet 1) de commencer un échange en HTTP, et donc notamment envoyer le bon Host: 2) puis passer en SSL.
Cf notamment §14.42 du RFC2616 (ok, UPGRADE n'est pas une méthode HTTP, désolé pour le raccourci)
Dans ce paragraphe je lis : "The Upgrade header field only applies to switching application-layer protocols upon the existing transport-layer connection."
Or si je ne m'abuse TLS/SSL est une couche de transport, non ?
Sauf que en pratique cela fonctionne, et c'est mis en oeuvre (ex: CUPS).
D'où problème résolu. Maintenant la bonne question c'est : pourquoi ce n'est pas devenu le comportement par défaut, plutôt que de réserver TCP/443 pour le HTTPS ?
Peut-être parce que ça ne plaît pas que la requête GET/POST/autre passe en clair, puisque transmise avant l'en-tête en question ?
Relisez le RFC...
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Cf la méthode HTTP qui va bien qui permet
1) de commencer un échange en HTTP, et donc notamment envoyer le bon Host:
2) puis passer en SSL.
Cf notamment §14.42 du RFC2616 (ok, UPGRADE n'est pas une méthode HTTP,
désolé pour le raccourci)
Dans ce paragraphe je lis :
"The Upgrade header field only applies to switching application-layer
protocols upon the existing transport-layer connection."
Or si je ne m'abuse TLS/SSL est une couche de transport, non ?
Sauf que en pratique cela fonctionne, et c'est mis en oeuvre (ex: CUPS).
D'où problème résolu. Maintenant la bonne question c'est :
pourquoi ce n'est pas devenu le comportement par défaut, plutôt que de
réserver TCP/443 pour le HTTPS ?
Peut-être parce que ça ne plaît pas que la requête GET/POST/autre passe
en clair, puisque transmise avant l'en-tête en question ?
Relisez le RFC...
--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Cf la méthode HTTP qui va bien qui permet 1) de commencer un échange en HTTP, et donc notamment envoyer le bon Host: 2) puis passer en SSL.
Cf notamment §14.42 du RFC2616 (ok, UPGRADE n'est pas une méthode HTTP, désolé pour le raccourci)
Dans ce paragraphe je lis : "The Upgrade header field only applies to switching application-layer protocols upon the existing transport-layer connection."
Or si je ne m'abuse TLS/SSL est une couche de transport, non ?
Sauf que en pratique cela fonctionne, et c'est mis en oeuvre (ex: CUPS).
D'où problème résolu. Maintenant la bonne question c'est : pourquoi ce n'est pas devenu le comportement par défaut, plutôt que de réserver TCP/443 pour le HTTPS ?
Peut-être parce que ça ne plaît pas que la requête GET/POST/autre passe en clair, puisque transmise avant l'en-tête en question ?
Relisez le RFC...
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
