Problème de PHP mode CGI sur OVH.

Bonsoir

Le serveur de mon site partenaire, va bientôt être refait avec des disques durs neufs, car l'un des actuels disques durs, est en train de rendre l'âme... Problème insoluble par les moyens habituels de gestion du raid, à cause d'un contexte particulier.

Le problème, c'est que le système d'exploitation que souhaite mon Dirlo, est la Relaase 2 d'OVH... qui ne supporte que des interpréteurs PHP en mode CGI, pas en mode CLI. ( Dixit le support d'OVH ).

Or... J'utilise, lancés à partir de scripts en Bourne Shell, des commandes de lancement de scripts php comme en ligne de commande, de cette manière :

php -q -f script.php $param 1 $param2 2>/dev/null

Là, l'interpréteur php est censé être en mode CGI, et le paramètre -q ( d'après le PHP Manual ), fait que cette commande ne générera pas les en-têtes HTTP que génère php en mode CGI.

Donc, théoriquement, ce paramètre -q fait que, tout se passe comme si php était en mode CLI.

Première question : Celà est-il vrai, à partir du moment où le problème du répertoire par défaut dans le script script.php , ne se pose pas ?

Maintenant, lors de ces lancements, le script script.php rend une valeur à la fin de son exécution, par des instructions genre : exit(0); ou : exit(-1); dans ce script.

Ces valeurs de retour, seront-elles disponubles dans la variable Shell $? , après le lancement de cette commande, comme si php était en mode CLI ?

Par exemple, voici un morceau d'un script en Bourne Shell :

Code:

#!/bin/sh

# On suppose que le PATH est suffisant pour accéder à l'interpréteur php en mode CGI...

$tmp_php=`which php`

$param1="ab"
$param2="cd"

$result=$tmp_php -q -f script.php $param1 $param2 2>/dev/null

if( [ $result -eq 0 ]; then
  # Traitement OK, le script s'est correctemenet exécuté.
else
   # Traitement d'erreur.
fi

exit 0

Celà va-t-il fonctionner, même si php est en mode CGI ?

Le paramètre -q sera-t-il suffisant, pour que tout se passe comme si php était en mode CLI ? ?


Troisième question : Les paramètres $param1 et $param2, sont récupérées dans le script script.php , de cette manière :

Voici le script script.php :

Code:

<?php
$argv = $SERVER['argv'];

$param1 = $argv[1];
$param2 = $argv[2];

echo $param1 . "\n";
echo $param2 . "\n";

exit(0);
?>

Est-ce que les valeurs de $param1 et $param2 seront correctement lues dans $SERVER['argv'] ?

Normalement, le résultat du lancement du script en Bourne Shell, devrait donner :

ab
cd

Est-ce que ce sera le cas, sinon où est l'erreur ?

Merci beaucoup de vos réponses.

Bien amicalement.

Jean François Ortolo

 

Bonsoir

Je change de question, car il me semble avoir trouvé une partie des réponses.

Le problème étant, de savoir si le fait d'avoir un interpréteur php en mode CGI ( sur une Release 2 d'OVH ), n'empêchera pas les trois sites de mon Dirlo ( dont mon site partenaire ), de fonctionner, voici le point où j'en suis arrivé, et la question qui me reste...

D'abord, j'ai sur mon ordinateur, un interpréteur php en mode cli ( php ), et un interpréteur php en mode cgi ( php-cgi ).

Le fait de faire, à partir d'un compte ( login ) Shell :

php-cgi -q -f script.php ab cd 2>/dev/null

puis :

echo $?

Cette dernière commande, rend bien la valeur retournée par l'instruction exit(-1); terminant le script script.php

J'obtiens : 255

Mon seul problème, est de différencier, les valeurs 0, des autres valeurs de retour.

Donc déjà, cette difficulté est surmontée.

Ensuite, le fait de faire celà, n'affiche pas les en-têtes http.

Si c'est le cas sur le serveur neuf de mon Dirlo, j'aurai toujours la ressource, de rajouter comme paramètre :

--no-header

Par exemple :

php-cgi -q --no-header -f script.php ab cd 2>/dev/null

Cependant, il y a un hic : Les paramètres "ab" et "cd" ne figurent pas dans la variable $argv dansle script script.php , dans les deux cas.

Dans le script script.php , il y a :

[ code]
<.php
$argv = $_SERVER['argv'];

$param1 = $argv[1];
$param2 = $argv[2];

echo $param1 . "\n";
echo $param2 . "\n";

exit(-1);
?>
[/code]


Le fait d'exécuter ce code de cette manière, me donne une erreur comme quoi $argv[1] n'est pas affectée, et itou pour $argv[2]

Même chose si $argv est utilisée sans passer par la variable $_SERVER

Donc, d'abord, il semblerait qu'avec un interpréteur php en mode CGI, il soit impossibe de passer des paramères à un script lancé en ligne de commande.

Cependant, je peux contourner ce problème, en alimentant deux fichiers texte param1.txt et param2.txt en amont du lancement du script script.php , à partir du script en Bourne Shell qui lancera cette commande ci-dessus, puis dans script.php, lire le contenu de ces fichiers texte, pour avoir les paramètres.

Problème résolu.


Maintnenant, reste le problèmes des redirections, urlrewriting, et headers php.

Là, on suppose que ce sont des scripts php accédés de l'extérieur, en mode web classique.

Ma question ( mes questions ), sont celles-ci :

1- A l'intérieur d'un tel script php, pour un serveur web Apache avec php en mode CGI, est-il possible de faire des redirections, du type :

header("Location: $autre_url");
exit;

Ceci, comme d'habitude, en supposant qu'on n'a rien affiché avant, et pas mis d'autres headers


2- Dans les même conditions, est-il possible de faire des urlrewriting avec un fichier .htaccess , avec soit : RedirectPermanent, soit RewriteRule, suivi de la rule ?

3- Dans une url rewriting avec RewriteRule, la source de la rule peut-elle avoir des paramètres ? par exemple transmettre les paramètres des éléments de l'url source entre parenthèses, dans les variables : $1, $2, etc... repris dans l'url cible ?

4- A propos des headers, est-il vrai, que l'on peut placer des instructions de headers dans ce genre de scripts php, pour peu que aucun caractère n'ait été écrit ?

Autrement dit : le PHP mode CGI, ne va-t-il pas générer ses propres headers en début de script, qui vont empêcher que l'on puisse en placer d'autres dans le script ?

Voici toutes ces questions, qui me semblent faire le tour de tout ce qui peut empêcher les trois sites de mon Dirlo, de fonctionner.

A part çà, je suppsoe qu'il est possible d'utiliser des fonctions Javascript et des meta html du type : Meta Refresh , etc...

Merci beaucou beaucoup de vos réponses.

Bien amicalement.

Jean François Ortolo


PS J'ai encore une dernière question, à propos de sessions.