Voir la version complète : DOCUMENT_ROOT ne sait plus ce qu'il veut
J'ai découvert un problème nouveau.
Le cas est le suivant:
un script php "script.php" appelé via une url du type:
http://www.mondomaine.com/mondossier/script.php/un/faux/chemin/dacces
ou
http://www.mondomaine.com/mondossier/script/un/faux/chemin/dacces
a une valeur de DOCUMENT_ROOT à /home/moncompte/www/mondossier
Alors que s'il est appelé par:
http://www.mondomaine.com/mondossier/script.php
la variable DOCUMENT_ROOT vaut /home/moncompte/www comme il se doit.
Cela ne fait que quelques jours, c'est pourquoi je l'attribue à mod_ort (encore une bourde de regexp ? :-) mais bon allez savoir...
TG
J'utilise la même bidouille que toi mais mon DOCUMENT_ROOT est tjs correct...
Par contre, j'ai remarqué qu'avec les dernières version de PHP, l'url du type : mondossier/script/un/faux/chemin/dacces ne marche plus :(
J'ai essayé de changer les paramètres de config de PHP mais ça ne change rien... donc je suis condamné à rester à PHP 4.3.2...
Est-ce que qq1 aurait une idée ?
Nous sommes au courant de ce bug. Il sera corrigé dans la
semaine.
OVH écrivait :
Nous sommes au courant de ce bug. Il sera corrigé dans la
semaine.
Eh non toujours pas en ce qui concerne mon problème.
Je dis ça juste pour pas que vous oubliiez, pas du tout pour mettre la pression ;)
Luke-info
05/03/2004, 11h33
Bonjour,
j'ai actuellement le meme probleme, et ca m'est tres genant car toutes mes pages font un appel a un include a la racine du compte....
avez vous une solution pour y remedier facilement, en evitant d'avoir a mettre tout le chemin d'acces en dur ?
Merci
Y-a-il une autre methode que $DOCUMENT_ROOT pour connaitre la racine d'un site en attendant que $DOCUMENT_ROOT refonctionne ?
OVH écrivait le 10-02-2004:
Nous sommes au courant de ce bug. Il sera corrigé dans la
semaine.
Après la semaine de 4 jours, la semaine de 2 mois... :confused:
Enfin je voudrais pas avoir l'air de faire que me plaindre, j'ai bien compris que vous êtes complètement débordés, mais quand même... :rolleyes:
En ce qui me concerne j'ai choisi d'utiliser le chemin absolu dans le seul script qui utilise une écriture /dir/monscript/faux/chemin/d/acces et d'espérer que personne n'appelle mon site avec des URL pourries pour les autres scripts (normalement y a pas de lézard).
Comme je ne crois pas avoir de risque de voir apparaitre des trous de sécurité, ça me suffit...
Joe BILL
16/03/2006, 10h35
Y'a t-il des news à ce sujet car je voulais savoir si il fallait bidouiller ou pas. En effet j'ai site à mettre en ligne qui utilise ces variables et donc qui ne marche pas.
Merci d'avance
Joe BILL
16/03/2006, 10h38
Je voulais savoir ce qu'il en était car je suis confronter à ce "bug" et je dois mettre un site en ligne.
Merci d'avance
la semaine derniere, le problème etait toujours là
Joe BILL
16/03/2006, 11h46
grrrrr, s'il vous plait ovh, vous auriez pas des news ??
Shadow aok
16/03/2006, 12h03
Définissez une variable globale dans un fichier qui contiendra l'équivalent du $DOCUMENT_ROOT et voilà ça ira en attendant.
Joe BILL
16/03/2006, 13h34
L'avantage du document_root était que je pouvais faire un include depuis un quelconque endroit du site (ex : depuis /racine ou /racine/rep1/rep2 ....) et j'arrivais sur le meme fichier. Etant donné que je ne gère pas le contenu du site (c'est a dire que les pages et répertoires sont créés dynamiquement) il était bien utile de pouvoir fair un lien fixe sur la racine. En fait ce que vous me proposer reviens au même car je ne vais toujours pas pouvoir faire un lien vers ce document de config, donc ....
A moins que quelqu'un me propose une autre solution pour faire pointer un include sur un fichier précis, quelque soit sont emplacement dans le site.
A une époque, j'utilisais ca:
ini_set("include_path", '.:./inc:../inc:../../inc');
require_once 'function.inc.php';
pour trouver le fichier function.inc.php dans le répertoire inc à la racine du site,
Je sais, c'est moche mais bon...
Shadow aok
16/03/2006, 14h43
$_SERVER['SCRIPT_FILENAME'] et avec strpos puis strstr tu ne gardes que la valeur qui devrait être celle de ton DOCUMENT_ROOT.
avec
$_SERVER['SCRIPT_FILENAME'] et avec strpos puis strstr tu ne gardes que la valeur qui devrait être celle de ton DOCUMENT_ROOT.
on obtiendra un resultat different si SCRIPT_FILENAME est dans /home/toto/domaine.com/www ou dans /home/toto/domaine.com/www/rep1/rep2
alors qu'on recherche /home/toto/domaine.com/www, que le script soit dans /home/toto/domaine.com/www ou dans /home/toto/domaine.com/www/rep1/rep2.
Est-ce juste ou je n'ai pas compris ?
Joe BILL
16/03/2006, 15h11
question bête peut on spécifier le include path dans le htaccess et si oui comment ?
Shadow aok
16/03/2006, 15h13
toto93 écrivait :
avec
on obtiendra un resultat different si SCRIPT_FILENAME est dans /home/toto/domaine.com/www ou dans /home/toto/domaine.com/www/rep1/rep2
alors qu'on recherche /home/toto/domaine.com/www, que le script soit dans /home/toto/domaine.com/www ou dans /home/toto/domaine.com/www/rep1/rep2.
Est-ce juste ou je n'ai pas compris ?
Le résultat sera le même car on coupe après www.
Joe BILL
16/03/2006, 15h17
c'est quand meme fou de devoir bidouiller pour une histoire de variable qui semble bugger, mais au debut du post il était question de correction, qu'en est il ?
Shadow aok
16/03/2006, 15h49
C'est peut-être fou mais ça permet de contourner le problème.
Bonjour à tous.
J'ai parcouru un peu le forum.
A l'heure actuelle, tous mes includes à l'aide de getenv('DOCUMENT_ROOT') ne fonctionnent pas.
lorque je suis à la racine de mon site il me renvoi :
/home/forumu/www ->> c'est donc OK
lorsque je suis dans un sous repertoire
/home
alors qu'il devrait renvoyer : /home/forumu/www/rep/
et lorsque je descend encore un peu
j'ai en retour /home/forumu/www au lieu de /home/forumu/www/rep/rep1/
bref rien ne va !
quelqu'un pour m'expliquer ?
merci
littlewings
11/12/2006, 14h43
Euh... Des nouvelles de ce bug ? Apparemment c'est toujours d'actualité...
Normalement non, ça a été corrigé y'a un moment déjà...
littlewings
13/12/2006, 19h56
Pourtant j'ai toujours ce même bug...
Bonjour,
Aujourd'hui le bug est toujours actif... ARRRRRRRG. Regardez le DOCUMENT_ROOT sur ce fichier test...:mad:
http://www.pdimension.net/photos36/test.php (URL avec redirection htaccess)
(à comparer avec http://www.pdimension.net/photos30-39/photos36/test.php URL sans redirection, qui là ne pose pas de problème)
Est-ce qu'une solution est à l'étude ?
Curieux en effet. :confused:
Je suis nouveau sur ce forum, et ne connaît pas trop son lien avec l'équipe OVH. Est-ce qu'il y a une chance pour qu'un membre officiel d'OVH passe ici et prenne en charge le problème ? :confused:
Sinon, comment avertir l'équipe, histoire de les relancer un peu à ce sujet, qui visiblement traîne depuis plus de deux ans...!! :eek:
Merci !
Peutch
Sinon, comment avertir l'équipe, histoire de les relancer un peu à ce sujet, qui visiblement traîne depuis plus de deux ans...!! :eek:
J'ai averti le support OVH pour ce bug sur le DOCUMENT_ROOT qui est incorrect quand on utilise de l'url_rewriting.
Le support me reçoit de manière plutôt sceptique : "Normalement, il ne devrait pas y avoir de problème à ce niveau." :o
Bah si y'a un problème ! Le type me demande de refaire un essai à sa sauce, n'ayant sans doute pas le temps de regarder le cas de test que j'avais préparé moi-même (voire mon message un peu plus haut), et même avec son truc, le bug est avéré (ce qui n'est pas un scoop) :p
http://www.pdimension.net/fwrite : document accédé avec réécriture
http://www.pdimension.net/tests/docroot.php : document accédé par sa "véritable" adresse
Magie ! Le premier document_root est erroné... J'attends la réponse du support... Je vous tiens z'au courant ! ;)
Peutch
Ça avance, ça avance ! ;)
J'ai soumis le problème à la hotline et ils me répondent :
J'ai transmis le problème à un administrateur, je vous recontacterai lorsque je pourrai vous fournir plus d'informations.
Donc peut-être ce problème sera-t-il résolu un jour... :p
En fait, ça n'avance pas tant que ça !
http://www.ovh.com/fr/espaceclients/support/support.cgi?id=20118114056610811463 pour toute la discussion, je mets ici des extraits choisis :
MOI :
Date : 2007-06-06 16:36:07
Correspondance :
Bonjour, ce bug n'est toujours pas corrigé, (cf. http://www.pdimension.net/fwrite) c'est vraiment pénible. Mon site est inutilisable !!!! Je paie pour rien !
J'apprécie le support rapide, et le fait que mes messages ne tombent pas dans le vide, c'est vraiment appréciable. Mais hélas rien n'est fait derrière...
Que font les administrateurs ? Va-t-il falloir que je leur écrive moi-même ?
OVH :
Date : 2007-06-08 12:18:22
Correspondance :
Bonjour,
Malheureusement nous n'avons toujours pas de solution concernant ce problème.Je ne peux donc pas vous en dire plus.
Je reste à votre disposition pour tout renseignement complémentaire.
Cordialement,Steve
MOI :
Date : 2007-06-10 19:46:08
Correspondance :
> Je reste à votre disposition pour tout renseignement complémentaire.
Oui, j'aimerais savoir à qui je dois m'adresser pour accélérer la correction de ce bug.
OVH :
Date : 2007-06-11 15:16:57
Correspondance :
Bonjour,
Malheureusement les amdinistrateurs ne sont pas joignable directelent via notre support.Vous pouvez directement ,dans ce cas là, nous ecrire au siège social:
SAS OVH
140 quai du Sartel
59100 Roubaix
Je reste à votre disposition pour tout renseignement complémentaire.
Cordialement,Steve
Là ça frise le délire. Envoyez un courrier papier à des administrateurs de serveurs ??? Alors que le problème est signalé, et "acknowledgé" par OVH, depuis plusieurs années...
C'EST N'IMPORTE QUOI !! ET ÇA COMMENCE À DEVENIR VRAIMENT, VRAIMENT ÉNERVANT...
Avez-vous d'autres infos ? Peut-être que si on les relance à plusieurs...
caaptusss
17/07/2007, 00h09
^^ Le support d'OVH fait des merveilles ces derniers jours :) J'en suis également trèèèès heureux (cf mon topic "Je deviens fou" dans le forum serveur dédiés)
Sivoupléééé...
Je suis en train de craquer là. Si quelqu'un a des infos sur ce bug... Déjà ça me ferait plaisir de savoir si je suis le seul à encore souffrir de ce bug. J'ai oublié de préciser que j'étais hébergé sur un 60gp.
Sinon, est-ce que quelqu'un a eu des nouvelles d'OVH à ce sujet ?
Déjà si on peut avoir une EXPLICATION du problème, ça serait un gros gros progrès. :confused:
Ensuite si c'était possible d'avoir une SOLUTION pas trop sale, genre en utilisant le .htaccess, ça serait encore mieux. (Enfin un truc qui évite d'avoir à recoder 120 pages qui font légitimement appel à DOCUMENT_ROOT. J'ai essayé avec un SetEnv dans .htaccess mais ça n'a pas l'air de fonctionner.) :o
Enfin, si on pouvait avoir une RÉSOLUTION, là ça serait souper !! :cool:
Merci aux admin d'OVH qui passent dans le coin !
Selon les normes http://fr2.php.net/manual/fr/reserved.variables.php#reserved.variables.server
'DOCUMENT_ROOT'
La racine sous laquelle le script courant est exécuté, comme défini dans la configuration du serveur.
OVH peut très bien avoir plusieurs générations de serveurs avec des OS différents et donc des valeurs qui peuvent changer selon les serveurs.
OVH n'a donc aucune obligation de fournir une valeur constante pour DOCUMENT_ROOT. ;)
OVH n'a donc aucune obligation de fournir une valeur constante pour DOCUMENT_ROOT. ;)
Oui mais en terme de programmation, c'est pas vraiment très pratique si un script fournit une réponse différente selon l'adresse par laquelle il est appelé...
Et à la limite, si OVH me fournissait une réponse de ce genre, je serais presque prêt à m'en contenter (mais pas vraiment content). Mais ils n'ont jamais rien fait de tel, depuis trois ans que le problème a été signalé...
oles@ovh.net
18/07/2007, 03h50
c'est le mod_ort qui change document_root, si tu me disais ce que
tu devrais avoir au lieu de nous laisser deviner ?
peutch <peutch.2tvyuz@no-mx.forums.ovh.com> a écrit:
Selon les normes http://fr2.php.net/manual/fr/reserved.variables.php#reserved.variables.server
OVH peut très bien avoir plusieurs générations de serveurs avec des OS différents et donc des valeurs qui peuvent changer selon les serveurs.
OVH n'a donc aucune obligation de fournir une valeur constante pour DOCUMENT_ROOT. ;)
La conclusion de ta deuxième phrase est tirée par les cheveux: le fait qu'Ovh n'ait pas un parc homogène n'entraîne pas automatiquement qu'Ovh ne doive pas fournir une valeur constante des variables SERVER. Rien que parce que sinon, c'est le bordel (tiens, ça me rappelle un autre fil de discussion... :D
À propos de normes, la page que tu cites ne dit pas que les hébergeurs ont le droit d'être bordéliques, mais que c'est malheureusement fréquent.
Et cette page renvoie à une autre, qui, elle, est la norme et qui est un peu plus rigoureuse: http://hoohoo.ncsa.uiuc.edu/cgi/env.html
Advp, tu est très gentil.
La conclusion de ta deuxième phrase est tirée par les cheveux: le fait qu'Ovh n'ait pas un parc homogène n'entraîne pas automatiquement qu'Ovh ne doive pas fournir une valeur constante des variables SERVER. Rien que parce que sinon, c'est le bordel (tiens, ça me rappelle un autre fil de discussion... :D
Tu as tout à fait raison.
En effet tu peux à tout instant traverser la route sur un passage clouté sans regarder à droite et à gauche. Selon le code de la route, les véhicules ont l'obligation de s'arrêter et de te laisser passer.
Personellement, je préfère regarder à droite et à gauche et . . . ne pas me faire écraser. ;)
Et cette page renvoie à une autre, qui, elle, est la norme et qui est un peu plus rigoureuse: http://hoohoo.ncsa.uiuc.edu/cgi/env.html
Mais quand on cite un document : http://hoohoo.ncsa.uiuc.edu/cgi/env.html on s'assure que l'information pour DOCUMENT_ROOT s'y trouve bien. Ce qui n'est pas le cas.
Advp, [...]
Non: "avdp", et non pas "advp".
En effet tu peux à tout instant traverser la route sur un passage clouté sans regarder à droite et à gauche. Selon le code de la route, les véhicules ont l'obligation de s'arrêter et de te laisser passer.
[...]
Ce genre de métaphore, on peut en faire plus d'une, toutes vraies bien que contradictoires.
Par exemple, on peut prendre celle de l'aviation: heureusement que les avions ont tous les mêmes unités de mesure pour l'altitude (notamment), hein !... parce que sinon... :eek:
Donc reste qu'un hébergeur dont les machines ne renvoient pas toutes les mêmes choses... c'est le bordel. Et par référence au codage avec les pieds, je dirais qu'un tel hébergeur fait un travail de cochon.
Mais quand on cite un document :
C'est toi qui a cité le document qui renvoie à cette page. :rolleyes:
Non: "avdp", et non pas "advp".
Excuse moi.
C'est toi qui a cité le document qui renvoie à cette page. :rolleyes:
Non, j'ai seulement cité le document fr2.php.net Variables de serveur : $_SERVER (http://fr2.php.net/manual/fr/reserved.variables.php#reserved.variables.server) qui lui contient bien une définition de DOCUMENT_ROOT.
Excuse moi.
Aucun caractère de gravité. ;)
Non, j'ai seulement cité le document fr2.php.net Variables de serveur : $_SERVER (http://fr2.php.net/manual/fr/reserved.variables.php#reserved.variables.server) [...]
Oui, et ce document fait référence à l'autre, dans cette phrase:
"Cependant, un grand nombre de ces variables fait partie des » spécifications CGI 1.1 (http://hoohoo.ncsa.uiuc.edu/cgi/env.html), et vous pouvez donc vous attendre à les retrouver.".
Mais bon, ce n'est pas l'essentiel. ;)
c'est le mod_ort qui change document_root, si tu me disais ce que
tu devrais avoir au lieu de nous laisser deviner ?
Salut Oles, merci de répondre. C'est vrai que de se taper tout le thread pour savoir quel est le problème d'origine est un peu relou. Alors je refais un bref résumé.
En fait, il semblerait que lorsqu'une redirection via htaccess intervient, le document_root renvoyé par le serveur (je suis sur 60gp) n'est pas le bon.
Exemple (suggéré par l'assistance OVH) :
http://www.pdimension.net/tests/docroot.php Ce document renvoie le DOCUMENT_ROOT attendu : /home/monlogin/www
http://www.pdimension.net/fwrite Cette adresse est redirigée vers pdimension.net/tests/docroot.php via RewriteRule dans le .htaccess ; mais la valeur fournie pour le DOCUMENT_ROOT est alors surprenante. /home/monlogin/www/tests
Et évidemment, dans ce dernier cas, moi ça m'arrangerait plus d'avoir le classique : /home/monlogin/www
Bizarre, z'avez dit bizarre... Une explication, Oles ?
Peutch
Allo Allo Allo allo Allo Allo
Y'a quelqu'un quelqu'un quelqu'un quelqu'un quelqu'un quelqu'un? :confused:
Bonjour à toutes et à tous,
J'ai le même souci également : l'url rewriting modifie la valeur de DOCUMENT_ROOT. Or, j'aimerais beaucoup pouvoir utiliser cette variable, histoire de simplifier mes livraisons du local vers la recette puis la prod sans devoir bidouiller à chaque fois plus qu'il ne faut...
Un correctif est-il prévu dans un avenir proche ?
Bonjour Kgb203,
Je rappelle ce que j'ai écris en #34 :
Selon les normes http://fr2.php.net/manual/fr/reserved.variables.php#reserved.variables.server
'DOCUMENT_ROOT'
La racine sous laquelle le script courant est exécuté, comme défini dans la configuration du serveur.
OVH peut très bien avoir plusieurs générations de serveurs avec des OS différents et donc des valeurs qui peuvent changer selon les serveurs.
OVH n'a donc aucune obligation de fournir une valeur constante pour DOCUMENT_ROOT. ;)
D'autre part, tu nous écris :
Bonjour à toutes et à tous,
J'ai le même souci également : l'url rewriting modifie la valeur de DOCUMENT_ROOT. Or, j'aimerais beaucoup pouvoir utiliser cette variable, histoire de simplifier mes livraisons du local vers la recette puis la prod sans devoir bidouiller à chaque fois plus qu'il ne faut...
Cela confirme ce que j'ai maintes fois écris :
Ne jamais utiliser la variable : $_SERVER['DOCUMENT_ROOT'] :D
Bonjour Abogil,
Je vous remercie pour votre réponse.
Un problème se pose toutefois à moi, du fait de cette restriction (mais vous vous en doutiez sans doute déjà :o ).
J'utilisais jusqu'à présent cette variable DOCUMENT_ROOT afin de réaliser mes includes (des classes PHP5, pour l'essentiel). Exemple : include_once($_SERVER['DOCUMENT_ROOT']."/classes/ma_classe.php");
Comment puis-je aujourd'hui remplacer cette variable ?
Il m'est bien évidemment impossible de remplacer, dans plusieurs dizaines pages, cette variable par une chaîne du type "/home/utilisateur/www/", qui ne correspond qu'à un unique environnement...
Je veux bien définir une nouvelle variable à laquelle je donnerais une valeur en fonction de l'environnement de travail (local, qualif, ou prod) dans un fichier séparé, mais comment inclure ce même fichier dans mes pages, dès lors qu'un include nécessite au préalable de connaître la racine du site ?
Il doit certainement, à vous lire, exister une solution très simple, mais je ne la vois a priori pas...
En vous remerciant d'avance pour votre aide,
Kgb
Bonjour à toutes et à tous,
Je me permets de relancer ce sujet car je suis actuellement coincé par le souci technique signalé précédemment...
Quelqu'un connaîtrait-il une méthode permettant d'éviter le recours à document_root ?
Daniel60
12/11/2007, 16h09
Je ne vois que l'utilisation d'un chemin relatif ../../classes/ (j'espère que je ne dis pas une bêtise :p )
Je déterre un "vieux" fil, mais les informations sur le sujet ne sont pas très courantes et je pense que cela pourra peut-être en aider certains...
Suite à la découverte du "bug" concernant document_root lors de la mise en place de l'url rewriting, et après de (très) nombreuses heures de recherche, voici la solution que je suis en passe de retenir pour obtenir le chemin absolu que permettait document_root. Mes premiers tests semblent tout à fait concluants:
remplacer (par exemple)
include($_SERVER['DOCUMENT_ROOT'] . '/include/fichier.php);
par
include(substr($_SERVER['DOCUMENT_ROOT'],0,stripos($_SERVER['DOCUMENT_ROOT'],'/www')+4) . '/include/fichier.php);
Si quelqu'un a trouvé mieux, je suis preneur ! ;)
Je déterre un "vieux" fil, mais les informations sur le sujet ne sont pas très courantes et je pense que cela pourra peut-être en aider certains...
Suite à la découverte du "bug" concernant document_root lors de la mise en place de l'url rewriting, et après de (très) nombreuses heures de recherche, voici la solution que je suis en passe de retenir pour obtenir le chemin absolu que permettait document_root. Mes premiers tests semblent tout à fait concluants:
remplacer (par exemple)
include($_SERVER['DOCUMENT_ROOT'] . '/include/fichier.php);
par
include(substr($_SERVER['DOCUMENT_ROOT'],0,stripos($_SERVER['DOCUMENT_ROOT'],'/www')+4) . '/include/fichier.php);
Si quelqu'un a trouvé mieux, je suis preneur ! ;)
Bonjour,
Etant à mon tour tombé sur le problème, et après quelques heures de recherche moi aussi (mais pas autant que toi probablement, d'autant que lorsque j'ai lu que tu y avais passé plein de temps, je me suis dit que ce n'était peut-être pas la peine que j'en passe autant moi-même...), je n'ai pas trouvé mieux. Ou plutôt :
1. J'ai trouvé ça : http://www.generation-nt.com/reponses/document-root-de-apache-chez-ovh-mutualise-entraide-28963.html#1
qui propose de mettre une variable d'environnement dans le .htaccess, dans laquelle le "vrai" DOCUMENT_ROOT serait mis en dur. Pourquoi pas, mais de toute façon la directive SetEnv n'a pas l'air de fonctionner (sur un 90gp en tout cas).
2. J'ai opté pour la solution que tu as proposée, que j'ai récrite comme suit (mettre ce code en tête du fichier par lequel on entre sur le site, si celui-ci existe -- ou s'ils ne sont pas trop nombreux) :
$expected_document_root_len = strpos($_SERVER['DOCUMENT_ROOT'], "/www") + 4;
if (strlen($_SERVER['DOCUMENT_ROOT']) > $expected_document_root_len)
$_SERVER['DOCUMENT_ROOT'] = substr($_SERVER['DOCUMENT_ROOT'], 0, $expected_document_root_len);
C'est un peu plus violent dans la mesure où ça écrase $_SERVER['DOCUMENT_ROOT'], mais d'un autre côté ça isole le correctif. Question de goût.
vBulletin® v.3.8.4, Copyright ©2000-2012, Jelsoft Enterprises Ltd. Tous droits réservés - Version française vbulletin-fr.org