Bonjour à tous,
Depuis le déploiement de HTTPS, il n'est pas possible d'appeler un lien de son propre site en HTTPS en utilisant curl (PHP), ou en appelant son propre site en HTTPS depuis un cron. L'erreur standard dans ce cas est "cURL error 35: error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol".
Une solution était d'appeler http://monsite.web:443 à la place de https://monsite.web.
Suite à vos retours, nous avons testé différentes solution et en avons validée une récemment. Nous allons donc la déployer, ce qui va rendre le HTTPS fonctionnel. Cependant, avec cette solution, le moyen détourné ne fonctionnera plus.
Nous prévoyons de le déployer en janvier. Le planning du déploiement sera ajouté ici prochainement, ainsi que sur la tâche travaux dédiée à cette migration : http://travaux.ovh.net/?do=details&id=22251
Joyeuses fêtes de fin d'année,
Vincent
Bonjour,
Donc, http://monsite.web:443 ne fonctionnera plus ? 
Donc, http://monsite.web:443 ne fonctionnera plus ? :sweat_smile:
Effectivement, c'est pour cela que nous annonçons la nouvelle à l'avance et que nous allons publier le calendrier précis des déploiements.
Oui, merci de prévenir de cette tâche travaux.
Cela dit, je ne suis pas sûr que tous ceux qui utilisent ":443" se méfieront de cette annonce étant donné que cette méthode avait été annoncée comme une solution pérenne de par la nature du protocole. Et c'était il y a même pas 6 mois.
Bonjour,
Je ne comprends pas du tout le problème. Si on veut appeler un lien de son propre site, pourquoi ne l'appelle-t-on pas par un lien relatif /repertoire ? Pourquoi essaie-t-on de l'appeler par https://nom-de-domaine/repertoire ? Même s'il s'agit en fait d'un lien dynamique (un fichier php ou autre langage web-serveur)
rci de prévenir de cette tâche travaux.
Cela dit, je ne suis pas sûr que tous ceux qui utilisent ":443" se méfieront de cette annonce étant donné que cette méthode avait été annoncée comme une solution pérenne de par la nature du protocole. Et c'était il y a même pas 6 mois.
Le soucis n'est pas lorsque l'on appele un autre élément de son site dans un navigateur (javascript / css / image / lien hypertext). Il a lieu lorsqu'un script PHP tente de faire un appel HTTP vers le site lui même. Sauf que ce script s'exécutant sur le serveur web local, il a accès au port 443 mais sans chiffrement, et curl n'accepte pas d'appel https sans chiffrement.
Il a été rapporté à plusieurs reprises sur ce forum et concerne aussi les crons (et sera bientôt de l'histoire ancienne !)
Il a lieu lorsqu'un script PHP tente de faire un appel HTTP vers le site lui même
Pourquoi ce script php passe-t-il par http alors qu'il essaie de joindre un fichier qui se trouve sur le serveur, là où se trouve le script lui-même?
J'ai un script toto.php qui essaie de joindre un fichier tata.bibule, si dans le fichier toto.php je spécifie le fichier tata.bidule par http://domain/repertoire/tata.bidule je comprends qu'il y ait problème, mais si je le spécifie par /repertoire/tata.bidule, il n'y aura pas de problème, si?
t-il par http alors qu'il essaie de joindre un fichier qui se trouve sur le serveur, là où se trouve le script lui-même?
Ah, ca il faut demander aux développeurs de ces scripts :slight_smile:
Mais généralement, il s'agit d'utiliser l'environnement HTTP ou de tester que le site fonctionne bien. Wordpress vérifie la bonne mise en place des mises à jour comme cela par exemple.
Oui, on avait été plusieurs à rapporter ce problème, et c'était sur l'ancien forum, ce qui montre bien que ce souci ne date pas d'aujourd'hui. Par contre, désolé, mais je confirme que vous nous disiez que c'était une solution pérenne d'utiliser http://site.com:443 dans les appels php. Mais bon, tout le monde peut se tromper un jour. 
J'ai un script toto.php qui essaie de joindre un fichier tata.bibule, si dans le fichier toto.php je spécifie le fichier tata.bidule par http://domain/repertoire/tata.bidule je comprends qu'il y ait problème, mais si je le spécifie par /repertoire/tata.bidule, il n'y aura pas de problème, si?
Oui, mais dans le premier cas, tu passes par la couche HTTP et le serveur web (Apache), et dans le deuxiéme cas, tu fais un require() du fichier directement depuis PHP. Ce ne sont pas les même usages !
Mais bon, tout le monde peut se tromper un jour. :stuck_out_tongue:
:) Tu tapes dans le mille !
Nous avons décidé de trouver une solution plus transparente car Wordpress (et d'autres CMS) utilisent massivement curl pour s'auto appeler et les changements que l'on vous proposait à l'époque ne sont pas simple à comprendre quand on maitrise pas un peu le code.
Y'a que les c*** qui ne changent pas d'avis :stuck_out_tongue:
Ps : Mais c'est aussi parce qu'on avait dit que ce serait pérenne qu'on prend le temps de communiquer !
Wordpress vérifie la bonne mise en place des mises à jour comme cela par exemple.
Mais même dans ce cas-là, le nom de ton domaine est en dur dans ton instance Wordpress? Dans un site Drupal ce n'est pas le cas, j'ai fait un clone d'une instance Drupal sur un autre hébergement en faisant un copier coller des fichiers et ça a marché. Il y a juste le nom de la base de données qu'il a fallu modifier.
Mais même dans ce cas-là, le nom de ton domaine est en dur dans ton instance Wordpress?
Oui, Wordpress le garde en dur (en database)
Oui, Wordpress le garde en dur (en database)
Eh ben c'est ça le hic, on pourrait s'en passer. Pour résumer je ne comprends pas la nécessité pour une appli web de "connaître" son nom de domaine pour s'appeler elle-même. Elle appelle des fichiers qui se trouvent au même endroit qu'elle-même , donc elle n'a pas besoin du nom de domaine, et donc pas besoin de passer par http(s).
Si c'est pour tester le protocole, ça ne me parait pas un bon test de le faire depuis la branche où tu es assis.
Pas de souci (mais un peu surpris au début). 
Effectivement, ça ne doit pas être simple de faire la modif sur Wordpress (avec en plus le risque de l'écraser à la prochaine màj).
Tu fais un lien absolu par exemple :
- si tu as plusieurs sites https sur le même hébergement et que tu veux que la page de ton site A récupère la page de ton site B via file_get_contents() par exemple. Le problème se produira car il est lié à tous les sites du même hébergement, pas seulement au site courant.
- si tu veux appeler une page de ton site avec des paramètres GET, via file_get_contents(). Ces paramètres ne seront pas pris en compte en lien relatif (même s'il y a surement des solutions pour les faire passer autrement).
- pour toutes les urls envoyées par les utilisateurs (dans le cas d'un avatar, vérifier si c'est bien une image, ses dimensions, etc.), image qui pourrait très bien provenir de l'un des sites de l'hébergement.
Ah oui, d'accord, c'est plus clair, merci de l'info.
Allez hop' OVH! Vous pouvez lâcher la sauce
C'est clair c'est le moment idéal ! Faudrait pas que ça soit lancé vers fin janvier…
Vous pouvez lâcher la sauce
Quelle sauce?