Finalement le problème vient du fait que la constante PHP_SAPI ne renvoie pas la chaine 'cli'

ça renvoi quoi alors ?

Bonsoir à tous.

laurentj a dit :

ça renvoi quoi alors ?

J'ai un autre problème, toujours lié à la mise en prod de mon appli.

J'utilise la fonction get_headers() (native PHP) dans un de mes scripts. Cela fonctionne en dev, et pas en prod ! Bizarrement, cette fonction renvoie toujours null lorsqu'elle est exécutée sur mon serveur de prod, quelque soit l'url que je lui passe en paramètre ???

Je me sert de cette fonction pour identifier l'url finale à partir d'une url initiale (prise en compte des redirections, raccourcisseurs...).
C'est bloquant pour moi : si je ne trouve pas de solution de remplacement, tout mon site tombe à l'eau.

J'ai cherché en vain un script qui ferait l'équivalent du get_headers() natif... Quelqu'un serait-il déjà tombé la-dessus ?

Merci pour votre aide :)

il faudrait demander à 1&1 pourquoi les infos de get_headers ne sont pas dispo

à mon avis, ton hebergeur bloque cette fonction, voir même bloque peut être les requêtes http vers l'exterieur. à toi de vérifier. Sinon, tu peux utilise jHttp, qui repose sur la lib pure php netHttp de clearbricks (regarde l'api dans lib/clearbricks/).

Pour l'histoire de PHP_SAPI, encore un hebergeur à la con qui met à disposition la version cgi plutot que cli, pour la ligne de commande. J'avais fait une correction en ce sens pour jelix-scripts, mais pour les applis en cli, il semble que la correction n'ait pas été faite au niveau de jConfigCompiler... Je vais m'en occuper.

Merci pour vos réponses,

Pour pallier au défaut de get_headers() sur mon hébergement mutualisé, je vais essayer de récupérer les entêtes http via cUrl : quelques exemples intéressants trouvés sur le net (quelle mine!) me laissent espérer une dénouement heureux.

laurentj a dit :
à mon avis, ton hebergeur bloque cette fonction, voir même bloque peut être les requêtes http vers l'exterieur. à toi de vérifier. Sinon, tu peux utilise jHttp, qui repose sur la lib pure php netHttp de clearbricks (regarde l'api dans lib/clearbricks/).

Pour l'histoire de PHP_SAPI, encore un hebergeur à la con qui met à disposition la version cgi plutot que cli, pour la ligne de commande. J'avais fait une correction en ce sens pour jelix-scripts, mais pour les applis en cli, il semble que la correction n'ait pas été faite au niveau de jConfigCompiler... Je vais m'en occuper.

N'y aurait-il pas un lien de cause à effet entre l'exécution de php en mode cgi et le "blocage" de certaines fonctions http ?

Re-bonsoir,

1) Mon problème "get_headers" est résolu (je me suis fais une fonction à base de cUrl qui fait très bien ce dont j'ai besoin).

2) En attendant les modifs de laurent dans jConfigCompiler... celles que j'y ai apportées moi-même ont résolues le problème "unknown module".

3) J'ai également opéré une petite modif dans jResponseCmdline.class.php pour régler les notice et warning évoqués dans le premier message.

Je vais donc mettre ce post en résolu !

Merci à tous pour votre aide.

Peut etre peux tu soumettre un patch de tes modifs voir si on les integre pour eviter que tu perdes celles ci à la prochaine mise à jour ;)

foxmask a dit :
Peut etre peux tu soumettre un patch de tes modifs voir si on les integre pour eviter que tu perdes celles ci à la prochaine mise à jour ;)

Tu as raison foxmask : j'ai prévu de prendre en main le plugin EGit pour Eclipse, ainsi j'espère pouvoir contribuer (il faut juste que je trouve un peu de temp ;))...

il semble que la correction n'ait pas été faite au niveau de jConfigCompiler... Je vais m'en occuper.

Je l'ai corrigé, c'est dispo dans la nightly de la 1.3.

Par contre j'ai oublié de corriger le souci sur STDERR...