etrange erreur / PHP

[korben080]

Bonsoir!

J'ai un petit problème en programmation Web:

Mon problème est étrange j'ai regardé partout sur de nombreux site mais peu de personne on l'air de vraiment connaitre la cause de cette erreur.

Voici donc mon message d'erreur:

Warning: Cannot modify header information - headers already sent by (output started at /var/www/free.fr/b/a/ashadows/AOSLEAGUE/page/hautDePage.htm:10) in /var/www/free.fr/b/a/ashadows/AOSLEAGUE/connection/connection.php on line 104

le plus etrange c'est que cette erreur est présente sur mon serveur wweb chez Free ( je c'est le gratuit on sais pourquoi c'est gratuit ... ) mais en local pas de problème.

Sur certains forum ils parlent d'une erreur qui serait du à l'hebregeur...

Je ne met pas plus d'information car je voudrais juste la cause de l'erreur mais si vous en avez besoin n'hesites pas.

Bon bin merci d'avance.

bye.

[Sentinel]

Le prblème est simple, et la solution encore plus, d'autant que le message d'erreur est parfaitement explicite : les headers HTTP doivent être envoyés en tout premier, avant toute autre forme de contenu.

Si tu utilises la commande Header, ce doit être la première instruction de ta page php.

Vérifie bien que tu n'envoies pas de texte, ou même d'espaces, avant la commande Header.

Le fait que cela fonctionne en local chez toi provient certainement d'une configuration différente de ton php.ini, et plus particulièrement du paramétrage du buffering. On peut en effet utiliser un buffer de 4k pour envoyer ses documents, auquel cas il est effectivement possible de placer les headers HTTP après du texte (du moment que les 4k ne sont pas encore remplis et que le buffer n'est donc pas encore envoyé).

Mais cette solution est à déconseiller. Free a un paramétrage bien étudié, et il est préférable de programmer propremement pour que ça passe chez eux.

(PS : EasyPHP est fortement déconseillé : sa configuration par défaut est une horreur, et a donné de très mauvaises habitudes à un grand nombre de développeurs amateurs...)

[warzi]

mmmh ?? quels genre de mauvaises habitudes?? etant un utilisateur de EasyPHP, j'aimerais savoir si je programme comme un boulet ou non

[korben080]

C'est gentil pr la petit "traduction" mais je ne suis pas completement débile et je n'utilise à aucun moment la fonction "header" au cours de mes pages.

Par ailleur j'utilise un "setcookie" qui est également placé dans l'entete HTTP. Le problème de "header" vient certainement d'ici mais je n'arrive pas a consevoir que l'on soit obligé de placer ses instanciations des cookies au debut de la page.

L'affectation d'un cookie dépendant principalement d'un choix de l'utilisateur que nous voulons conserver je ne vois pas pourquoi le mettre des le debut.

(on ne va pas stocker le cadi d'un client avant que celui si ait choisi ses articles non ?!)

Merci quand même et ci quelq'un a une idée...

Bye

Et que conseils tu à la place de EasyPhp ? Apache only ainsi que MySql ?

De plus chez Free je n'ai pas accès au fichier php.ini pour mofifier la taille du buffer.

J'ai entendu dire que ce paramettre pouvais se renseigner dans un fichier .htaccess ?

A - non B - oui

C - peut être D - ta fumé !

50/50

Vote du public

Appel à un ami

...

[theocrite]

Alors dans l'ordre :

1/

Tu ne peut pas appeller setcookie au millieu de ta page : http://www.nexen.net/docs/php/annotee/function.setcookie.php

"es cookies doivent passer avant tout autre en-tête (c'est une restriction des cookies, pas de PHP)".

Mais les cookies, cay mal. Pense aux sessions.

2/

EasyPHP n'est pas une mauvaise solution IMHO. Ca ne se veut pas une interface de production, mais de développement rapidement exploitable.

Dailleurs à l'install on a bien un warning : "Easy php est prévu pour un environement de développement, pour la production préférer une solution LAMP" (ce qui est le cas de free).

Mais bon, ce n'est pas une mauvaise idée d'installer séparément Apache, PHP et MYSQL.

Tu as apache 2 dispo ici, mais je te conseille quand même le 1.3 (qui est la même version que free) : http://httpd.apache.org/download.cgi . Même chose pour php : tu as le php 5 de dispo ici : http://www.php.net/downloads.php, mais je te conseille plutôt php4.

Et pout mysql, prends la 4.0. Je ne sais pas ce qu'a free, mais bon, ça me semble le meilleur choix : http://dev.mysql.com/downloads/.

3/

htaccess n'a rien à voir avec le php.ini. Il reprend une partie de ce qu'il y a dans le httpd.conf, (l'autentification) que tu peut dailleurs récupérer dans un script avec $REMOTE_USER

4/ D - Tu as fumé, c'est mon dernier mot Jean Pierre

[korben080]

OK bien merci le probleme vient donc du fait que j'appelle cette fonction "setcookie" apres certainne balise html.

ce qui ne m'arrange pas étant donnée que j'ai besoin de ces balises html pour récupérer l'information que je veux stocker dans mes cookies.

Mais bon j'ai déjà une petite idée de comment faire.

Et bien merci beaucoup.

CHAO

PS: moi j'aurai pri le 50/50 au moins

[theocrite]

Si tu as une idée, tant mieux. Mais comme je l'ai dit plus tôt, tu peut utiliser les sessions qui sont stockées coté serveur, ce qui n'est pas plus mal.

Sinon, il me semble que pour les cookies il faut que tu force le rafraichissement de la page.

[korben080]

oui oui t'inkietes pas je connais l'objet "session" mais la ce n'est pas e but recherché. Je me sert aussi de ce dernier pour autre chose

Je veux me servir des cookies juste pour stocker les paramêtres de connexion pour une futur visite.

Parce que ce que je faisais jusqu'a maintenant c'est que lors de la conexion d'un visiteur donc renseignement des champs pseudo et pwd et envoie du formulaire si ce client avait une authentification valide je faisais setcookie et je le créais en y stockant toutes les donneés (pseudo +pwd).

Hors maintenant des le debut je vais créer mon cookie (setcookie) mais vide et apres je le recupérerais avec $_cookies["nomDuCookie"]

Ca devrait faire l'affaire.

Une fois le cookie récupérer avec cela $_cookies["nomDuCookie"]

Il y a bien moyen d'y modifier la veleur ?! non . avec un pti :

$_cookies["nomDuCookie"]->value ou un truc comme ca ca doit le faire. Je V aller voir ca

en pofinant tout ca, ca devrait le faire.

Merci encore.

[theocrite]

Je vois. J'espère que ça va fonctionner. Mais sinon, tu as toujours la possibilité de rentrer ces informations dans une Base de Données.

[ingeni]

pour la fonction header, tu peux l'appeler quand tu veux à condition de n'avoir rien envoyer comme contenu (comprendre réponse au client)

output started at /var/www/free.fr/b/a/ashadows/AOSLEAGUE/page/hautDePage.htm:10

ça signifie que tu as envoyé du html à cette ligne ...

Pour EasyPhp, c'est po une mauvaise plateforme, surtout la 1.7 qui est configuré par défaut pour sortir toutes les erreurs.

Pour ma part, j'ai installé apache 1.3 et php5 pour pouvoir programmer en php5... c stable même si ma confg de php et apache et parfois bancal (faut dire que mon code est parfois à la limite ...).

[korben080]

Bonjour!

Je ne vois pas comment stocker le login et le pwd dans la base de données.

Enfin si je vois comment mais je ne vois pas le but.

Moi j'utilise les cookies pour le bur premier a savoir laisser sur le poste client des informations propres a ce dernier.

Mais hier trop grosses soirée pas U le temps d'essayer.

Sinon pour répondre a Jaco:

Oui le problème vient de la : j'envoie déjà des balises HTML avant mes cookies.

Parce que enfaite j'ai ma page "HautDePage.htm" qui contient tout le détail de ma page html (style,body,...) et ensuite j'ai ma page avec mes cookies et ces 2 dernières sont inclues dans une autre page.

accueil.php:

include ("./hauteDePage.html");
include ("./cookies.php");

Donc la on voit nettement la cause de mon erreur et vous direz et bien il suffit d'inverser. Mais le problème c'est que dans mon fichier "cookies.php" il y a le formulaire permettant de se connecter à mon site donc si j'inverse ces 2 fichiers mon formulaire se trouvera avant mon entete.

Bref tout cela pour vous mettre au courant de mes "betises". Il va juste me suffir de décomposer mon cookies de mon formulaire et de faire un teste de ce style:

accueil.php:

if(isset($_POST["login"] && isset($_POST["pwd"] )
{
 include ("./cookies.php");
}
include ("./hauteDePage.html");
include ("./formulaire.php");

Enfin un truc qui ressemblera à cela et ca devrai passer.

Et bien merci bien pour le coup de main.

Et je vous tiens au courant ci j'ai d'autre problèmes.

Bye

[theocrite]

Je ne vois pas comment stocker le login et le pwd dans la base de données.

Enfin si je vois comment mais je ne vois pas le but.

Pour identifier quelqu'un qui est déja venu. Il faut bien qu'il tape un mot de passe. Donc il faut que tu en stoque un, non ?

[tuXXX]

faut utiliser les $_SESSION pour voir si le gars est loggé, et quand il rentre son mdp, regarder par rapport à la bas de donnée (mySQL, par exemple)...

En gros, il ne devrait y avoir que $_SESSION qui bouge, le cookie est généré automatiquement par php, l'authetification peut se faire de manière sécurisée, avec stockage des mdp en md5 ou sha1 dans la base de donnée...

[theocrite]

Ah, enfin quelqu'un qui dit comme moi

[korben080]

Oui Oui !

Messieurs !

Je suis 2000 fois d'accord avec vous c'est d'ailleurs ce que j'ai mi en place.

J'ai bien une base données où le client est recensé avec login et pwd.

Il vient sur mon site se log : la je verifie si ds la base de données son compte est valide.

Puis je stocke des info dans l'objet session ($_SESSION) pour qu'il puisse se promener partout dans le site sans a avoir a retaper son log et pwd.

Par contre le client s'en va et coupe son PC. Il revient moi je ne veux pas qu'il ai a retapper sont authentifiaction je veux ke tout soit déjà inscri dans les champs. Il ne lui restera donc plus qu'a cliker sur "connexion".

D'ou l'utilité du cookie car la session correspond a une ouverture de session HTTP vers le serveur donc apres avoir coupé son poste il ne pourra plus avoir la même session.

Donc je suis bien d'accord avec vous mais le but est juste de stocké pour une future visite ses identifiants et la à part le cookie je ne vois pas, a moins qu'une nouvelle technologie soit sortie ...

Vous savez quand meme que l'on parle de la même chose et que nous sommes d'accord...

$_SESSION qui bouge, le cookie est généré automatiquement par php

Oui le cookie de session donc serveur. Mais moi je veux un vrai cookie du coté client.

Donc la la session ne répond pas a mes besoins.

Car vous dans vos sites ( je presume que vous developpez aussi des sites ...) pour se logguer il faut toujours retaper vos identifiants ??

A plush

[tuXXX]

D'ou l'utilité du cookie car la session correspond a une ouverture de session HTTP vers le serveur donc apres avoir coupé son poste il ne pourra plus avoir la même session.

si...

il y a une option dans le serveur ph pour garder l'identification plus ou moins longtemps, je crois...

mais normalement, si le serveur est bien configuré, le cookie de session est créé et reste, donc plus besoin de se logger ensuite...

et je parle bien du cookie côté client...

[korben080]

Le problème est que je n'ai pas accès à la configuration du serveur. Donc je ne peux pas regler la session.

De plus qui dit requette http dit @ IP donc avec une ligen ADSL ki change tous les jours la session ne serait valide que 24h.

Et tu parles de session et de cookie en meme temps donc je ne sais plus du quel tu veux parler.

parce ke le cookie de session celui je l utilise et il marche bien.

Mais le cookie (classique) coté client c'est lui avec lekel j avais des problèmes.

Mais tu dis que le cookie est géré authomatiquement.

Comment ?

Moi je ne vois pas comment stocker sur le client son login et son pwd autrement qu'avec un cookie généré suite a un "setcookie"

Je suis ouvert a tout nouveau chok emotionnel:

Si quelqu'un a une solution qui remet en cause tous les principes vu en cours : je prends

Merci

Bye

[warzi]

je pense qur tuXXX voulais dire que si tu gardais plus longtemps d'identification de session, tu pourrais recuperer ton client a sa prochaine connexion

mais a mon avis il se trompe. korben080 veut que le client (logiciel) s'identifie des la connexion (comme sur PCInpact quand sa marche ) et pas que le client (user) doive taper ses infos. Or l'identifiant de session change a chaque fois que tu crées une nouvelle fenetre de l'explorateur internet malgré le fait que sous IE (je connais pas les autres) l'identifiant est herité quand tu fais "ouvrir dans une nouvelle page" mais si tu ouvresdeux fenetres en executant 2*IE, tu auras deux sessions differentes. cela est sûr puisque je l'ai decouvert en programmant un site en php recemment

[tuXXX]

ben d'après la doc que j'ai lue :

http://www.nexen.net/docs/php/annotee/session.security.php

http://www.nexen.net/docs/php/annotee/session.idpassing.php

http://www.nexen.net/docs/php/annotee/func...okie-params.php

la sessions php peuvent être transmises par l'url ou par cookie chez l'utilisateur...

il est même possible de changer la durée de vie (dernier lien) du cookie de session...

[tuXXX]

mais a mon avis il se trompe. korben080 veut que le client (logiciel) s'identifie des la connexion (comme sur PCInpact quand sa marche ) et pas que le client (user) doive taper ses infos. Or l'identifiant de session change a chaque fois que tu crées une nouvelle fenetre de l'explorateur internet malgré le fait que sous IE (je connais pas les autres) l'identifiant est herité quand tu fais "ouvrir dans une nouvelle page" mais si tu ouvresdeux fenetres en executant 2*IE, tu auras deux sessions differentes. cela est sûr puisque je l'ai decouvert en programmant un site en php recemment

c'est vrai que je n'ai pas essayé...

ce serai bizarre, quand même

[warzi]

a mon avis tu ne comprend pas le concept de session.

une session commence lorsque tu te connectes sur un site avec des session

le numero de session correspond a un code md5 (heure d'ouverture du logiciel ou un truc du genre)

quand tu te balades, tu gardes ton numero puisque ton logiciel reste ouvert.

lorsque tu ferme ta fenetre ta session se ferme (oubli du numero de session).

et lorsque tu te reconnectes, tu arriveras avec un nouveau numero puisque nouvelle heure et nouvelle ouverture du logiciel. il est donc impossible pour le serveur de savoir que c'est toi.

tu devras te reidentifié. manuellement ou a l'aide d'un cookie

[tuXXX]

ah ben peut-être, alors...