Mutualisé et erreur 500 en php (résolu)

HerveG2 2017-01-13 21:27:33 UTC #6

Je ne vois pas le rapport : il ne s'agit pas de dev mais juste d'un script, et c'est pas mon boulot...

Je lis sur le lien envoyé : "Erreur de script Si vous programmez en perl par exemple, une erreur dans votre script se résume en une erreur 500. Vous ne pouvez pas avoir plus de details (question de securité). Pour debugger vos scripts, vous pouvez utiliser la connexion telnet/ssh (possible à partir de l’offre Pro)."

Donc pour résumer OVH cache sciemment les erreurs php sur ces hébergements sous prétexte de sécurité et pour obliger à prendre une option pro... Comme si il n'y avait que les pro pour écrire une petite moulinette de convertion d'une BDD vers une autre... Je ne vais pas me monter un serveur à la maison rien que pour tester un script de convertion d'une galerie photo vers une autre... (Même Free le permet sur les pages perso !) Bon, pas grave, j'ai un dédié aussi, je vais me tourner vers lui, mais si j'avais su j'aurais pas renouvelé ce matin un hébergement à 100€ qui ne me permet pas de bosser autrement qu'en utilisant du "tout fait tout prêt", et sans être pro...

Merci de vos infos

Buddy 2017-01-13 21:47:22 UTC #7

Le rapport est que c'est le fonctionnement d'OVH actuellement. Je ne dis pas que c'est logique ou pas, je dis que c'est le plus rapide (pour être/avoir été confronté au même problème).

Si tu as payé ~100 € ton hébergement, tu as déjà l'hébergement pro.
Le perso à l'année est plutôt autour de 40-45 €.

Gaston_Phone 2017-01-13 21:50:01 UTC #8

Il faudrait savoir si l'erreur 500 est liée à ton fichier /www/.htaccess ou non.
Pour cela tu devrais faire le test du script bonjour.php : OVH - Erreur 500 sur votre site Internet

HerveG2 2017-01-13 22:19:20 UTC #9

J'ai un "Offre Mutualisée Pro 2014 - 12 mois" et ça merde quand même, et un petit dédié... Bref, chez OVH ça devient du cache misère ? (je cache les erreurs pour qu'on pose pas de questions ?) Pas grave je vais m'arranger autrement, c'est clair que j'aurais préféré ne pas monter un serveur juste pour avoir "syntaxe incorrecte ligne 12 manque le ; à la fin"...

Et c'est pas un soucis de htaccess car en multi site j'ai déplacé le script sur plusieurs sites avec des environnements différents et c'est la même erreur... Je vais tester demain mais j'espère que les BDD du mutualisé sont accessibles de mon dédié, sinon c'est vraiment monter une usine à gaz pour un script de 100 lignes et qui va mettre 9 secondes à corriger 1000 lignes d'une table !

Nowwhat 2017-01-14 08:15:49 UTC #10

Si, avec des scripts (.html, .php, .htaccess, etc) prêt à l'emploi.
Coder soi même sur un Mutu, pourquoi pas, ça fait plus que 10 années que j'adapte mes scripts sur des Mutus.
Un "500" n'est pas un simple erreur de syntax PHP, mais carrément un encodage d'un fichier (BOM ou autre), voir un htaccess avec le même souci ou un syntax erreur dans ce fichier.

Non.
Il suffit de 'résoudre' (à partir de ton mutu, chez 'toi' ou à partir de ton dédié t'arrivera même pas) l'adresse URL de ton serveur MySQL que tu utilise pour ton Mutu : surprise : il s'agit des adresses IP non-routable, genre 10.x.x.x. qui sont locales pour les serveurs web - mais pas du tout accessible pour d'autre hosts sur l'internet, dont ton dédié.

J'aurais fait ça sur un petit dédié justement .... - pas sur un Mutu

Daniel60 2017-01-14 08:25:04 UTC #11

Il est fort probable que ce soit un problème d'encodage de caractères ou de fins de ligne.
Qu'utilises-tu comme éditeur et client FTP ?

HerveG2 2017-01-14 08:37:17 UTC #12

ben non : notepad++ et utf8 sans bom, depuis toujours... et selon les cas winscp ou filezilla

heu là je viens de tester sur mon dédié le même script, donc machine différente et domaine différent : erreur 500, gloups...

HerveG2 2017-01-14 08:40:58 UTC #13

Encore plus étonnant : je viens de mettre un partie de mon script entre "/* */" sauf les affichages, et là ça passe mutu ou dédié... donc il s'agit bien d'une erreur de syntaxe qui devient erreur 500 !

Je vais tester tronçon par tronçon, c'est pas un gros script pour trouver la ou les lignes qui provoquent ça...

HerveG2 2017-01-14 08:49:29 UTC #14

C'est bien ce que je pensais : en remettant des morceaux de code en 3 ou 4 fois, ça fonctionnait, et puis est apparu une erreur de syntaxe comme d'habitude me signalant une ")" de trop que j'ai corrigé et maintenant tout fonctionne normal aussi bien mutu que dédié... Aucun autre changement... Je ne comprend pas mais bon !

Buddy 2017-01-14 09:08:26 UTC #15

Bonjour sur ton dédié,
Tu peux avoir l'erreur en te connectant en ssh en allant dans le bon repertoire et en tapant.
Php ton fichier.Php

Ça marche aussi peut être sur le mutu.

Daniel60 2017-01-14 10:17:33 UTC #16

Curieux en effet qu'une erreur de syntaxe PHP se traduise par une erreur 500.
Qu'en pensent les techies ?

Ludo.H 2017-01-14 10:46:06 UTC #17

Bonjour,

Avec une connexion SSH, se connecter sur votre MUTU et tenter un :

# php script_qui_produit_la_500.php

Et voir le retour ?

Sinon le mode development doit remonté les erreurs, mais dans le cas d'une 500, le process php plante et donc ne peut rien remonté... il faut regarder les logs.

Avec un nom de domaine on peut le faire directement sur la machine pour vous.

Cdt,

HerveG2 2017-01-14 10:59:58 UTC #18

Je n'ai pas configuré le ssh sur le mutu car pas eu l'usage contrairement au dédié.
Je viens de tenter de reproduire l'erreur mais pas moyen car si je remet l'erreur de syntaxe j'ai bien maintenant "Parse error: syntax error, unexpected ')' in /home/welcomepwg/www/dressage-chien.fr/edu/php/....php on line 59", c'est encore moins clair cette histoire, d'autant que le dédié me renvoyait la même erreur... Si ça se trouve c'était mon pc ou notepad qui ont été pris de démence

Pour investigation le domaine c'est dressage-chien.fr et j'ai testé aussi sur educador.fr sur le même mutualisé et aussi sur varioflux.com mais là c'est sur mon dédié.

HerveG2 2017-01-14 11:07:35 UTC #19

D'ailleurs sur le dédié le fichier y est encore et provoque toujours la même erreur puisque je n'y ai pas retouché depuis ce matin : http://varioflux.com/edu/audiogal.php

Ludo.H 2017-01-14 12:33:03 UTC #20

Bonjour,

L'erreur dans le texte :

# /usr/local/php5.6/bin/php audiogal.php

<ul>1 bud2.jpg bud2 PHOTO</ul><ul>2 bud.jpg bud PHOTO</ul><ul>3 briska2.jpg briska2 PHOTOErreur UPDATEngg_picturesSET alttext = 'Briska2', description = 'Briska, Jack Russell's Terrier mâle' WHERE pid=263 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 's Terrier mâle' WHERE pid=263' at line 1

Cdt,

HerveG2 2017-01-14 17:28:19 UTC #21

Non désolé, vous n'avez pas suivi...
Ceci est le message actuel qui n'a plus rien à voir avec le problème d'origine, d'ailleurs ce message est affiché à l'écran normalement... Depuis le début j'indique que les erreurs SQL ressortent bien mais que les erreurs de syntaxe du php elles et elles seule sortaient en erreur 500, ce qui est l'objet de ce message.
Vous voulez une image du problème tel que rencontré ? http://varioflux.com/edu/audiogal.php
Là vous aurez l'erreur 500 et c'est strictement le même écran qui ressortait sur tous les tests mutu ou dédié... Maintenant, et comme ça ne se produit plus j'imagine qu'il s'agissait d'un soucis avec notepad++ car d'un seul coup tout s'est remis en ordre et je ne sais plus reproduire le problème (sauf sur le lien donné car c'est le fichier php d'origine inchangé depuis ce matin)

Bref, il semble que ça se soit réparé tout seul, donc encore merci à tous et désolé pour le bruit

HerveG2 2017-01-18 15:18:23 UTC #22

Bon, pour clore le sujet, je pense avoir cerné le problème :

Dans la pratique j'utilisais Filezilla et la fonction "éditer" qui m'ouvrait directement le .htaccess dans notepad++, et dans 1 ou 2 autres cas (pas cherché la raison basique) il m'a récupéré des fichiers et les a considéré comme encodé en ansi au lieu de utf8 sans bom... Je crois que quand il n'y a pas d'accentué dans un fichier le codage n'est pas indiqué, donc de temps en temps soit filezilla soit notepad++ se plante et renvoie le fichier en ayant modifié ce paramètre, d'où l'erreur 500 provoqué...

En espérant que ça aide quelqu'un un jour et éviter qu'il ne perde autant de temps que moi sur ce détail !

Nowwhat 2017-01-18 15:53:20 UTC #23

T'as trouvé LA raison pourquoi j'ai balancé FileZilla (gratuit) pour SmartFTP (payant, mais quel bonheur).

Daniel60 2017-01-18 16:11:07 UTC #24

Il s'agissait donc bien d'un problème d'encodage...
Lorsqu'il s'agit de code pur (Apache ou PHP) l'UTF-8 n'a aucun intérêt car seul l'ANSI est interprété. Avec ou sans BOM c'est une source de problème. A réserver au cas où tu as du textuel littéral niché dans le code avec un affichage prévu.
Concernant Filezilla, j'ai pris pour habitude de travailler en local avant de transférer et en principe l'extension .php est traitée correctement.

vcasse 2017-01-19 09:13:11 UTC #25

Merci d'avoir indiqué la solution à ton probléme.

A bientôt,
Vincent

Propulsé par Discourse, le rendu est meilleur avec le JavaScript activé

OVH Community

Bienvenue sur votre espace communautaire. Posez des questions, recherchez des informations, publiez du contenu et interagissez avec d’autres membres OVH Community.