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
Appels HTTPS depuis son site ou un cron
Sujets apparentés
- [RESOLU] Server unable to read htaccess file, denying access to be safe
25754 
24.11.2019 19:11
- Version php 7.0 sur Ovh mais php 5.4.45 sur mon wordpress
22960 10.01.2019 11:14
- Comment récupérer son mot de passe phpmyadmin ?
19933 14.11.2016 10:32
- Changer la version d'une base de donnée en mutualisé
19745 22.12.2016 11:46
- Variable upload_max_filesize plus grande que post_max_size
19723 11.06.2017 16:01
- Résiliation hébergement+domaine
15444 11.09.2018 20:28
- Résiliation hébergement
14605 27.07.2018 10:39
- Transfert hebergement et domaine .fr entre client OVH ?
13800 21.12.2016 15:10
- Ne supporte pas FTP sur TLS
13777 11.12.2018 18:48
- Nouvelle fonctionnalité : SFTP pour tous
13461 06.01.2017 14:50
Bonjour,
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)
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 !)
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?
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. :stuck_out_tongue:
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 !
:) 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 !
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.
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). :slight_smile: 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 :p
C'est clair c'est le moment idéal ! Faudrait pas que ça soit lancé vers fin janvier...
Quelle sauce?
La sauce https qui fonctionne avec Curl :p
Ah ok :blush:
On dit pas "lacher la sauce" mais "envoyer le purée" :blush:
Ba, il y a de la sauce CUR(i) ;)
Pourquoi est ce que ce sera plus bloquant fin janvier pour vous ?
Cordialement,
Vincent
Bonjour,
Je crois que nous sommes une poignée à trouver cela assez urgent comme problème. Donc plus rapidement, c'est déployé mieux c'est ;)
Peut-être que pour votre équipe à OVH, vous pensez que cela est quelque chose de bénin, mais croyez-nous c'est plus qu'handicapant, c'est clairement pas viable. Beaucoup d'extensions ne fonctionnent clairement plus entre autres.
Oh non, nous ne pensons pas que c'est bénin ! Cependant, nous préparons la communication pour les gens qui ne suivent pas le forum ou la mailing list et que utilisait le moyen dérobé de http://:443.
Nous allons statuer le planning de déploiement trés prochainement.
Cordialement,
Vincent
Et bien, la plupart des modules de sauvegarde et de sécurité ne fonctionnent plus. Les pings et cron WordPress non plus. Quelques widgets basés sur les flux aussi...
Vivement la résolution
Je teste plusieurs solutions mais non efficaces à 100 %
On attend impatiement
Comment seront nous contactés ?
Et Bonne Année
Toutes les informations sur le déploiement seront indiquées ici même et dans cette tâche travaux : http://travaux.ovh.net/?do=details&id=22251
Il y a-t-il beaucoup d'éléments bloquants que l'on ne remarque toujours pas le fix arriver?
D'après la todo list et de ce que j'ai compris, ça se ferait fin janvier.
Toujours aucune date officielle annoncée ? :(
ça urge ...
Nous venons de publier le calendrier du déploiement sur la tâche travaux.
http://travaux.ovh.net/?do=details&id=22251
Bonne soirée,
Vincent
Super merci pour les dates ;)
Super, merci pour les dates ;)
Bonjour à tous,
Nous sommes prêts à déployer le correctif.
La première phase étant une phase de test, elle va se dérouler au compte goutte sur des comptes que nous allons surveiller de près. Si par hasard vous disposez d'un compte **perf** et que vous souhaitez bénéficier du correctif en avant-première vous pouvez nous fournir votre nom de domaine. Nous ferons le nécessaire pour installer le correctif sur le serveur qui vous est dédié.
Cordialement,
Guillaume.
Bonjour,
Je vous ai envoyé en message privé, le domaine concerné pour bénéficier du correctif en avant première.
Merci
Bonjour,
et si sur les hébergements mutualisés vous voulez commencer par le cluster 14, surtout ne vous gênez pas ... :)
Merci
Bonjour,
Le déploiement suit bien son cours ? La tâche travaux n'a pas été actualisée depuis 2 jours.
Bonjour chmod777,
En effet il y a eu un léger retard dans le déploiement, qui a été rattrapé aujourd'hui.
cluster015 et cluster020 sont toujours au programme pour demain.
Cordialement,
Guillaume.
Bonjour @GuillaumeL
Effectivement, j'ai posté dans ce sujet à 11:19 et la tâche travaux a été actualisé à... 11:19. :laughing:
Le fix a également déployé sur le cluster 13 mais malheureusement ça ne fonctionne pas de mon côté et ça a même cassé la solution de contournement avec http:443.
J'avais mis en place un simple fichier de test pour justement pouvoir vérifier que tout allait bien le jour où le fix serait déployé. Ce fichier contient deux fois la fonction php file_get_contents_, la première occurrence utilisant https:// et la deuxième http:443. Les deux partent donc en erreur désormais :
> Mode HTTPS :
> Warning: file_get_contents(https://www.site.net/images/logo.jpg): failed to open stream: HTTP request failed! HTTP/1.1 503 Service Temporarily Unavailable in /home/site/www/test.php on line 6
> Mode HTTP:443 :
> Warning: file_get_contents(http://www.site.net:443/images/logo.jpg): failed to open stream: HTTP request failed! in /home/site/www/test.php on line 9
Erreurs presque identiques, à part ce "HTTP/1.1 503 Service Temporarily Unavailable" dont j'ignore la raison (le fichier appelé existe bien et est accessible depuis un navigateur).
J'utilise le CDN... C'est peut-être la cause ?
Merci.
Hello,
Ca devrait être bon sur cluster013, le cluster s'est auto-ban...
Le fix est en cours.
Cdt,
Merci Ludo.
Ca a bien fonctionné une première fois sur mon script de test, puis l'erreur était de retour quelques minutes après. Peut-être que le fix n'est pas encore complètement déployé ?
Bonjour,
C'est en parti corrigé à partir de maintent (75% des cas), une correction définitive d'ici demain.
Cdt,
Ca semble ok maintenant de mon côté en tout cas. Merci. :+1:
sur les travaux (http://travaux.ovh.net/?do=details&id=22251) tout est terminé.
Hors je suis sur le cluster 15, je viens de faire un essai
(redirection global vers https, et planification d'un article ) et bien le cron (via wordpress) ne fonctionne plus du tout (plus de trace dans les logs)
Et mon cache ne marche plus il m'envoie le fichier gz au lieu de la page !.
Obligée de retirer la redirection globale
et du coup j'ai le message cURL error 35: error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol (que je n'avais pas avant d'essayer la redirection ce matin)
Hello,
Chez nous tout est ok (AutomotivPress.fr / cluster 015). Avec le cache WP Rocket, pas de problème (nous avons abandonné WP Super Cache).
La redirection SSL est ok (nous n'avions pas retenu la solution 443).
On va tester le Cron WP aujourd'hui pour voir si la planification d'articles est valide.
j'ai effectivement Super Cache ...
Une chose que je ne comprends pas non plus, si le cron du cluster est bien passé en SSL
pourquoi dans mon log j'ai un cron qui se lance en http
POST /wp-cron.php?doing_wp_cron=1486638125.4740920066833496093750 HTTP/1.1" 200 25 "http://xxxxxx.com/wp-cron.php?doing_wp_cron=1486638125.4740920066833496093750" "WordPress/4.7.2; https://xxxxxxx.com
Hum, apparemment le Cron de WP ne permet plus de planifier des tâches... même avec la MAJ d'OVH :confused:
D'un autre coté dans le log de mon site testeur (sur cluster 15) n'apparait que des cron initié en http, alors que sur les sites avec cluster 13 (basculé avant, mais je ne veux pas tester dessus) apparait un cron http et un cron https ... étrange ...
Cron https arrivé sur le cluster 15
j'ai refais les tests avec redirection en place.
La planification WP a eu du mal a démarrer (en plus pb avec la liaison strasbourg), mais ca marche maintenant ..
A noter : Wp-super -cache fonctionne moyennant l'activation d'un paramètre dans wp-cache.php (le pb est connu et la solution expliquée sur la page du plugins) .
Tout est fonctionnel donc.
Merci à tous.
Pour palier en attendant que les travaux effectués , j'ai testé WP Fastest Cache pendant un mois
et vu les résultats je le garde parce que nettement meilleur que super cache
ça vaut le coup d'essayer
le seul problème avec WP Fastest Cache c'est que pour qu'il fonctionne aussi pour les mobiles, il est payant ... je me trompe ?
pour augmenter les performances pour les mobiles
mais l'amélioration est déjà importante avec la version free
sur mon premier j’ai deja la vitesse de chargement presque de moitié
il est installé en parallèle avec Autoptimize qui améliore bien aussi
Vu les excellents résultats, je l'ai installé sur quatre site et pour l'instant je ne pense pas revenir à super cache...
Bon dimanche :slight_smile:
Hello,
Je confirme que la planif' des articles fonctionne à nouveau sur le cluster 015. Comme CaroleP, le Cron WP est à nouveau opérationnel ... \o/
Bonjour !
C’est un sujet vraiment passionnant qui réveil toute ma curiosité et je ne m’en lasse pas même après l’avoir lu et relus.
Merci !