METEOQUEW[PHP] : RÉCUPÈRE LES INFOS DE METEOFRANCE

Commentaire de mickbad le 17/05/2006 22:17:21

mouais mouais mouais ... les fichiers semblent corrompues !
tu travailles sous MAC ? (pa'que ya un sous dossier __MACOSX)

Merci
.Mick.

Commentaire de stepibou le 18/05/2006 02:36:30

ici les boucles seraient apreciables.

a+

Commentaire de BaroqueW le 19/05/2006 14:56:10

Pour l'instant non. Ca dépend des versions de php des serveurs apparemment. Sur mon mac en PHP 4.3.9, ça passe et sur un serveur linux en PHP 4.4.0, ça ne passe plus.

Commentaire de neolien le 19/05/2006 15:45:08

Merci pour ta réponse rapide !

Dans le doute j'ai mis des CHMOD 777 sur les deux fichiers, je pencherais donc plus pour une configuration Apache de mon Hébergeur et notamment du "fsockopen" qui semble être verrouillé !

Merci quand même et dommage que je ne puisse pas l'installer sur mon dernier site de voyage : http://www.voyage-location.com

@++

Commentaire de mickbad le 19/05/2006 16:20:42

Salut,

Je reviens donc pour donner mon avis sur le problème rencontré avec le implode().

Je ne sais pas si, NEOLIEN, il s'agit du même problème mais je ne crois que faire un chmod 777 arrangerait les choses :)

En fait j'ai repéré 2 erreurs (ou 4 si on veux) et je serais tenté de dire : "ben voilà ce qui arrive qd on programme un truc n'importe comment" ! [dis avec le sourire naturellement sans volonté de blesser ;)]

Pourquoi je dis ça ?
- pas beaucoup de commentaires (debug pas facile à faire) à l'intérieur des fonctions
- des morceaux de codes (fonctions) sur une ligne : mouais
- des indentations dans tous les sens (du moins pour mon éditeur PSPad)
- des variables non déclarées mais utilisées (pas de pbm ok mais ce n'est pas propre et ça génère des NOTICEs sur certains serveurs)

M'enfin, tu as compris BaroqueW je ne trouve ça pas très joli à regarder et qd tu veux débusquer un bug ce n'est pas si facile que ça (surtout sans connaitre ni le code ni la pensée de l'auteur :))

Personnellement (je dis bien *personnellement*), je programme toujours en me disant que quelqu'un d'autre va lire le code pour me forcer à bien présenter les choses.
Mettre tout sur une ligne par exemple n'est pas top parfois et l'idée de "gagner de la place" n'est pas bonne.

Et puis, soyons NOUS aussi des artistes ! :)

BaroqueW, ne t'offusque absolument pas car je dis simplement mon avis dans le simple but de t'aider. Je n'ai pas la science infuse mais je pense que quelque part je n'ai pas tort :))


Au niveau des erreurs que j'ai trouvé :
- (pour moi du moins), les fonctions parsehost et parsepage n'ont pas forcément accès aux variables mis en tant que global. J'ai mis:
global $meteohost, $meteoIP;

- Dans ces mêmes fonctions, après la connexion et le test  de la validité du descripteur de fichier $fp, tu envoies la requête : fputs($fp,"GET ".$url2." HTTP/1.1\n\n");
Tu ne remarques pas ? 2 fois \n\n
C'est tellement bête et invisible que c'est évident :)

=> Tu indiques au serveur que tu as fini l'en-tête par une ligne vide. Seulement, tu envoies encore des données d'où le BAD REQUEST qui en ressort.
(pour le voir fait un echo $line après la réception de la réponse du serveur)

Sinon pas la peine de faire un \r\n, un \n suffit amplement car ce n'est pas du texte à lire directement avec un éditeur normal. Euh moi pas trop clair mais faire des efforts à l'avenir :))))


j'espère avoir aidé
Noelien, dit nous si c'est ça ton erreur :)

bye
.Mick.

Commentaire de BaroqueW le 19/05/2006 23:45:18

Un grand merci à MickBad pour avoir trouvé que l'erreur venait des \r\n et \n\n. Maintenant j'ai deux questions pour lui : pourquoi certaines versions de php font que ça répond bien et d'autres non ? et pourquoi ethereal me dit que mon navigateur émet bien des requêtes finissant par \r\n (au même endroit) ?
Mais sinon merci bien, j'ai même fait des efforts sur l'indentation et les commentaires :)

Commentaire de BaroqueW le 20/05/2006 12:46:17

En effet, il y avait des caractères étranges qui se glissaient dans certaines prévisions et elles n'étaient pas vues par mon script, tout doit être rentré dans l'ordre là. En tout cas, chez moi ça marche sur un grand nombre de villes.

Commentaire de BaroqueW le 20/05/2006 18:31:35

Justement, je parse la page reçue à la recherche de " 800 " et je le vire vu qu'expérimentalement, il n'a rien à faire là et vient tout le temps se fourrer PILE au niveau de la seconde "prévision météo". Tu es sûr que ça le fait quand même chez toi avec ma dernière version ?

Sinon, ça fait un peu plus d'un mois et demi que leur code HTML a pas changé, je croise les doigts !

Et les données récupérées sont bien gratuites et publiques, oui. Mais je viens de voir que l'article 2 du §3 de leur Licence d'Utilisation (http://www.meteofrance.com/FR/index.jsp#) interdit "l'extraction répétée et systématique d'éléments même non protégés du site causant un préjudice à METEO-FRANCE."
Après je suis pas sûr qu'une requête HTTP par-ci par-là soit préjudiciable au niveau serveur pour eux. Mais évitez de les flooder, merci :)
Et pas de XML en vue, mais ils doivent en faire un payant pour les sites commerciaux je suppose.

PS pour Mick : j'essaye le HTTP 1.0 demain

Commentaire de sharkit le 24/05/2006 08:34:09

Bonjour tout le monde
J'ai testé pour les depts outre mer, et la requète ne reconnait pas ( FR/mameteo/ que j'ai changé par FR/voyage/, suivant le type d'url que météo france envoies entre autre), savez quels paramatre il faudrait changer pour que l'on puisse interroger les dom ( notamment la Réunion ) ?
Merci pour tout

Commentaire de BaroqueW le 14/06/2006 00:27:24

Ca marche encore chez moi
Vérifie que ton hebergeur n'a pas changé des réglages au niveau php (version, sécurité etc.)

Pour l'outre-mer, je ne sais pas et je n'ai pas trop de temps en ce moment, désolé :(