probleme de chargement interrompu de donnees par socket.
8 réponses
Jean-Francois Ortolo
Bonjour
Je fais du chargement de données de sites externes par des fonctions
de socket telles que fsockopen, suivie de fputs ( pour la requête )
puis de fgets ( pour le header ), puis de fread pour les données.
J'utilise les fonctions données par un Américain sur les commentaires
de la fonction fsockopen(), dans le PHP Manual.
// Première fonction de l'Américain,
// pour détecter les contenus chunked,
// et permettre la décompression si besoin
// lors de la lecture des données.
$info=decode_header($send);
unset($send);
$send = '';
while(!feof($fp))
{
// il faut un fread pour interpréter le contenu
// brut en binaire.
$send .= fread($fp, 16384);
}
fclose($fp);
// Deuxième fonction de l'Américain,
// elle interprète les contenus chunked ou compressés,
// et les restitue suivant ce qu'indique le contenu
// de l'header.
$send = decode_body($info, $send);
// Enfin, on met le contenu
// dans une array.
unset($var);
$var = split("[\n]", $send);
// Et voila, le contenu de la page html
// est dans la variables indicée, ligne par ligne.
Tout se passe comme si les données dans certains cas ( aléatoires )
n'alimentaient pas correctement la variable $var, qui ne contient pas
la balise <head>, détectée par eregi("<head>", $donnee)
Cependant, j'ai mis un timeout de 300 secondes à l'ouverture du
socket ( d'ailleurs c'est sûr que le socket est ouvert, car le
traitement d'erreur ne détecte rien ), ce qui largement suffisant car le
paramètre $host est en réalité l'adresse ip en dur, qui est correcte.
De plus j'ai spécifié un time out pour les données de 3000 secondes,
soit 50 minutes, et d'ailleurs le timeout apparent réel, est de l'ordre
de 3 ou 4 minutes.
Je lance ces chargements de manière répétitive pour différentes pages
du même site, et à peu près une fois sur 7 ou 8 ( aléatoire ), la balise
<head> n'est pas détectée dans la variable indicée $var[]
Je parcours la variables $var avec un indice de 0 à (count($var) -
1), ce qui devrait être correct.
Je fais subir à chaque lignes rencontrées, une conversion de
utf-8vers iso-8859-15 avec la fonction decode faite de cette manière:
// pour sortir de la boucle
if(eregi("<\/html>", $donnee))
break;
// pour débuter le traitement
if(eregi("<head>", $donnee))
$trouve = true;
if($trouve)
{
// Traitement...
}
}
Le problème, c'est que dans certains cas, le traitement ne se fait
pas du tout.
Il ne devrait pas y avoir de problème, les données sont des pages
html en utf-8, qui devraient bien être traduites en iso par la fonction
decode(). D'ailleurs pour un autre site du même genre, çà marche.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Olivier Miakinen
Bonjour,
Le 22/07/2008 22:46, Jean-Francois Ortolo a écrit :
Je fais du chargement de données de sites externes par des fonctions de socket telles que fsockopen, suivie de fputs ( pour la requête ) puis de fgets ( pour le header ), puis de fread pour les données.
J'utilise les fonctions données par un Américain sur les commentaires de la fonction fsockopen(), dans le PHP Manual.
// Première fonction de l'Américain, // pour détecter les contenus chunked, // et permettre la décompression si besoin // lors de la lecture des données. $infoÞcode_header($send);
Est-ce qu'il ne serait pas plus simple d'utiliser Curl qui fait déjà tout ça et beaucoup plus ? <http://fr2.php.net/curl>
unset($send); $send = '';
La première de ces deux lignes ne me paraît pas très utile, vu qu'il y a la deuxième.
[...]
// Deuxième fonction de l'Américain, // elle interprète les contenus chunked ou compressés, // et les restitue suivant ce qu'indique le contenu // de l'header. $send = decode_body($info, $send);
Idem supra (à propos de Curl à la place du code de l'Américain).
// Enfin, on met le contenu // dans une array. unset($var); $var = split("[n]", $send);
1) L'unset() est inutile ; 2) dans une expression régulière, "[n]" est équivalent à "n" ; 3) preg_split() est généralement plus rapide que split() ; 4) explode() est toujours plus rapide que split() ou preg_split() ; 5) les fins de ligne sont censées être en rn.
Donc, je remplacerais bien les deux lignes ci-dessus par : $var = explode("rn", $send);
Donc, voici mon problème:
Tout se passe comme si les données dans certains cas ( aléatoires ) n'alimentaient pas correctement la variable $var, qui ne contient pas la balise <head>, détectée par eregi("<head>", $donnee)
Quand tu dis que c'est aléatoire, cela veut dire que la même valeur de $send donne parfois un $var correct et parfois un $var incorrect ? Ou bien est-ce que pour toi « aléatoire » est un synonyme de « je n'ai pas su dire quelle différence est significative » ?
[...]
Je lance ces chargements de manière répétitive pour différentes pages du même site, et à peu près une fois sur 7 ou 8 ( aléatoire ), la balise <head> n'est pas détectée dans la variable indicée $var[]
Ce qu'il faudrait savoir, c'est quel est le contenu exact de $send, puis celui de $var (la fonction print_r() est ton amie).
Je parcours la variables $var avec un indice de 0 à (count($var) - 1), ce qui devrait être correct.
Il y a plus simple : <http://fr.php.net/foreach>.
Je fais subir à chaque lignes rencontrées, une conversion de utf-8vers iso-8859-15 avec la fonction decode faite de cette manière:
function decode($var) { $send = ereg_replace("r$", "", $var);
Vu que tu as fait le split() avec "n" et qu'il est censé n'exister aucun "r" seul dans un flux HTML/HTTP, un str_replace avec "r" devrait suffire (à supprimer complètement si tu as déjà suivi mon conseil de l'explode() avec "rn").
Je ne savais pas qu'on pouvait utiliser les deux paramètres //TRANSLIT et //IGNORE l'un derrière l'autre. C'est bon à savoir, merci.
$send2 = str_replace(chr(189), "oe", $send1);
Tiens ? Tu n'aimes pas le « ½ » ? Pourquoi lui particulièrement et pas, par exemple, « ¼ » ou « æ » ?
$send3 = str_replace("r", "", $send2);
À supprimer si tu as suivi les conseils précédents.
[...]
// pour débuter le traitement if(eregi("<head>", $donnee)) $trouve = true;
Attention, même si je n'en ai jamais vu, il est possible de mettre des attributs lang et dir à l'élément HEAD. Par ailleurs en HTML il est même autorisé d'omettre la balise <head> (de même que la balise </html> que tu testes plus haut).
Le problème, c'est que dans certains cas, le traitement ne se fait pas du tout.
Procédons par ordre. 1) Est-ce que le contenu de $send est déjà incorrect ? 2) Est-ce que le contenu de $send est correct mais pas celui de $var ? 3) Est-ce que le contenu de $var est correct mais ça échoue quand même ?
Il ne devrait pas y avoir de problème, les données sont des pages html en utf-8, qui devraient bien être traduites en iso par la fonction decode(). D'ailleurs pour un autre site du même genre, çà marche.
Tu as une URL pour qu'on voie au moins le contenu envoyé ?
D'où vient l'erreur ? ;)
Excellente question, à laquelle tu es pour le moment le seul à pouvoir répondre. Commence par les trois questions ci-dessus ($send incorrect, $var incorrect ou traitement incorrect).
Cordialement, -- Olivier Miakinen
Bonjour,
Le 22/07/2008 22:46, Jean-Francois Ortolo a écrit :
Je fais du chargement de données de sites externes par des fonctions
de socket telles que fsockopen, suivie de fputs ( pour la requête )
puis de fgets ( pour le header ), puis de fread pour les données.
J'utilise les fonctions données par un Américain sur les commentaires
de la fonction fsockopen(), dans le PHP Manual.
// Première fonction de l'Américain,
// pour détecter les contenus chunked,
// et permettre la décompression si besoin
// lors de la lecture des données.
$infoÞcode_header($send);
Est-ce qu'il ne serait pas plus simple d'utiliser Curl qui fait déjà
tout ça et beaucoup plus ? <http://fr2.php.net/curl>
unset($send);
$send = '';
La première de ces deux lignes ne me paraît pas très utile, vu qu'il y a
la deuxième.
[...]
// Deuxième fonction de l'Américain,
// elle interprète les contenus chunked ou compressés,
// et les restitue suivant ce qu'indique le contenu
// de l'header.
$send = decode_body($info, $send);
Idem supra (à propos de Curl à la place du code de l'Américain).
// Enfin, on met le contenu
// dans une array.
unset($var);
$var = split("[n]", $send);
1) L'unset() est inutile ;
2) dans une expression régulière, "[n]" est équivalent à "n" ;
3) preg_split() est généralement plus rapide que split() ;
4) explode() est toujours plus rapide que split() ou preg_split() ;
5) les fins de ligne sont censées être en rn.
Donc, je remplacerais bien les deux lignes ci-dessus par :
$var = explode("rn", $send);
Donc, voici mon problème:
Tout se passe comme si les données dans certains cas ( aléatoires )
n'alimentaient pas correctement la variable $var, qui ne contient pas
la balise <head>, détectée par eregi("<head>", $donnee)
Quand tu dis que c'est aléatoire, cela veut dire que la même valeur de
$send donne parfois un $var correct et parfois un $var incorrect ? Ou
bien est-ce que pour toi « aléatoire » est un synonyme de « je n'ai pas
su dire quelle différence est significative » ?
[...]
Je lance ces chargements de manière répétitive pour différentes pages
du même site, et à peu près une fois sur 7 ou 8 ( aléatoire ), la balise
<head> n'est pas détectée dans la variable indicée $var[]
Ce qu'il faudrait savoir, c'est quel est le contenu exact de $send, puis
celui de $var (la fonction print_r() est ton amie).
Je parcours la variables $var avec un indice de 0 à (count($var) -
1), ce qui devrait être correct.
Il y a plus simple : <http://fr.php.net/foreach>.
Je fais subir à chaque lignes rencontrées, une conversion de
utf-8vers iso-8859-15 avec la fonction decode faite de cette manière:
function decode($var) {
$send = ereg_replace("r$", "", $var);
Vu que tu as fait le split() avec "n" et qu'il est censé n'exister
aucun "r" seul dans un flux HTML/HTTP, un str_replace avec "r" devrait
suffire (à supprimer complètement si tu as déjà suivi mon conseil de
l'explode() avec "rn").
Je ne savais pas qu'on pouvait utiliser les deux paramètres //TRANSLIT
et //IGNORE l'un derrière l'autre. C'est bon à savoir, merci.
$send2 = str_replace(chr(189), "oe", $send1);
Tiens ? Tu n'aimes pas le « ½ » ? Pourquoi lui particulièrement et pas,
par exemple, « ¼ » ou « æ » ?
$send3 = str_replace("r", "", $send2);
À supprimer si tu as suivi les conseils précédents.
[...]
// pour débuter le traitement
if(eregi("<head>", $donnee))
$trouve = true;
Attention, même si je n'en ai jamais vu, il est possible de mettre des
attributs lang et dir à l'élément HEAD. Par ailleurs en HTML il est même
autorisé d'omettre la balise <head> (de même que la balise </html> que
tu testes plus haut).
Le problème, c'est que dans certains cas, le traitement ne se fait
pas du tout.
Procédons par ordre.
1) Est-ce que le contenu de $send est déjà incorrect ?
2) Est-ce que le contenu de $send est correct mais pas celui de $var ?
3) Est-ce que le contenu de $var est correct mais ça échoue quand même ?
Il ne devrait pas y avoir de problème, les données sont des pages
html en utf-8, qui devraient bien être traduites en iso par la fonction
decode(). D'ailleurs pour un autre site du même genre, çà marche.
Tu as une URL pour qu'on voie au moins le contenu envoyé ?
D'où vient l'erreur ? ;)
Excellente question, à laquelle tu es pour le moment le seul à pouvoir
répondre. Commence par les trois questions ci-dessus ($send incorrect,
$var incorrect ou traitement incorrect).
Le 22/07/2008 22:46, Jean-Francois Ortolo a écrit :
Je fais du chargement de données de sites externes par des fonctions de socket telles que fsockopen, suivie de fputs ( pour la requête ) puis de fgets ( pour le header ), puis de fread pour les données.
J'utilise les fonctions données par un Américain sur les commentaires de la fonction fsockopen(), dans le PHP Manual.
// Première fonction de l'Américain, // pour détecter les contenus chunked, // et permettre la décompression si besoin // lors de la lecture des données. $infoÞcode_header($send);
Est-ce qu'il ne serait pas plus simple d'utiliser Curl qui fait déjà tout ça et beaucoup plus ? <http://fr2.php.net/curl>
unset($send); $send = '';
La première de ces deux lignes ne me paraît pas très utile, vu qu'il y a la deuxième.
[...]
// Deuxième fonction de l'Américain, // elle interprète les contenus chunked ou compressés, // et les restitue suivant ce qu'indique le contenu // de l'header. $send = decode_body($info, $send);
Idem supra (à propos de Curl à la place du code de l'Américain).
// Enfin, on met le contenu // dans une array. unset($var); $var = split("[n]", $send);
1) L'unset() est inutile ; 2) dans une expression régulière, "[n]" est équivalent à "n" ; 3) preg_split() est généralement plus rapide que split() ; 4) explode() est toujours plus rapide que split() ou preg_split() ; 5) les fins de ligne sont censées être en rn.
Donc, je remplacerais bien les deux lignes ci-dessus par : $var = explode("rn", $send);
Donc, voici mon problème:
Tout se passe comme si les données dans certains cas ( aléatoires ) n'alimentaient pas correctement la variable $var, qui ne contient pas la balise <head>, détectée par eregi("<head>", $donnee)
Quand tu dis que c'est aléatoire, cela veut dire que la même valeur de $send donne parfois un $var correct et parfois un $var incorrect ? Ou bien est-ce que pour toi « aléatoire » est un synonyme de « je n'ai pas su dire quelle différence est significative » ?
[...]
Je lance ces chargements de manière répétitive pour différentes pages du même site, et à peu près une fois sur 7 ou 8 ( aléatoire ), la balise <head> n'est pas détectée dans la variable indicée $var[]
Ce qu'il faudrait savoir, c'est quel est le contenu exact de $send, puis celui de $var (la fonction print_r() est ton amie).
Je parcours la variables $var avec un indice de 0 à (count($var) - 1), ce qui devrait être correct.
Il y a plus simple : <http://fr.php.net/foreach>.
Je fais subir à chaque lignes rencontrées, une conversion de utf-8vers iso-8859-15 avec la fonction decode faite de cette manière:
function decode($var) { $send = ereg_replace("r$", "", $var);
Vu que tu as fait le split() avec "n" et qu'il est censé n'exister aucun "r" seul dans un flux HTML/HTTP, un str_replace avec "r" devrait suffire (à supprimer complètement si tu as déjà suivi mon conseil de l'explode() avec "rn").
Je ne savais pas qu'on pouvait utiliser les deux paramètres //TRANSLIT et //IGNORE l'un derrière l'autre. C'est bon à savoir, merci.
$send2 = str_replace(chr(189), "oe", $send1);
Tiens ? Tu n'aimes pas le « ½ » ? Pourquoi lui particulièrement et pas, par exemple, « ¼ » ou « æ » ?
$send3 = str_replace("r", "", $send2);
À supprimer si tu as suivi les conseils précédents.
[...]
// pour débuter le traitement if(eregi("<head>", $donnee)) $trouve = true;
Attention, même si je n'en ai jamais vu, il est possible de mettre des attributs lang et dir à l'élément HEAD. Par ailleurs en HTML il est même autorisé d'omettre la balise <head> (de même que la balise </html> que tu testes plus haut).
Le problème, c'est que dans certains cas, le traitement ne se fait pas du tout.
Procédons par ordre. 1) Est-ce que le contenu de $send est déjà incorrect ? 2) Est-ce que le contenu de $send est correct mais pas celui de $var ? 3) Est-ce que le contenu de $var est correct mais ça échoue quand même ?
Il ne devrait pas y avoir de problème, les données sont des pages html en utf-8, qui devraient bien être traduites en iso par la fonction decode(). D'ailleurs pour un autre site du même genre, çà marche.
Tu as une URL pour qu'on voie au moins le contenu envoyé ?
D'où vient l'erreur ? ;)
Excellente question, à laquelle tu es pour le moment le seul à pouvoir répondre. Commence par les trois questions ci-dessus ($send incorrect, $var incorrect ou traitement incorrect).
Cordialement, -- Olivier Miakinen
Jean-Francois Ortolo
Olivier Miakinen a écrit :
Bonjour,
Le 22/07/2008 22:46, Jean-Francois Ortolo a écrit :
>>
D'où vient l'erreur ? ;)
Excellente question, à laquelle tu es pour le moment le seul à pouvoir répondre. Commence par les trois questions ci-dessus ($send incorrect, $var incorrect ou traitement incorrect).
Cordialement,
Bonjour Monsieur
Je suis en train de mettre dans des fichiers "avant.htm" et "apres.htm", les contenus bruts de var[$i] et decode($var[$i])
Je n'ai plus qu'à lancer le script.
Je pourrai consulter ces fichiers, pour savoir les contenus exacts de $var[$i], et dans quelle mesure le décodage a un impact sur les données.
Je vous tiens au courant.
En ce qui concerne le "rn" à la fin des lignes des pages html, je n'étais pas sûr de cela. Au cas où il puisse y avoir un simple saut de ligne, ne serait-ce qu'un seule fois, j'aurais bien des problèmes avec explode("rn", $send)
La raison pour laquelle j'utilise un indice numérique, est que je peux incrémenter cet indice comme je veux à l'intérieur de la boucle de lecture, pour les besoins du traitement. Il me semble que je ne le pourrais pas avec une boucle foreach().
Merci beaucoup pour vos conseils.
Bien à vous.
Amicalement.
Jean-François Ortolo
-- Visitez mon site gratuit donnant des Statistiques, des Pronostics et des Historiques Graphiques sur les Courses de Chevaux: http://www.ortolojf-courses.com/
Olivier Miakinen a écrit :
Bonjour,
Le 22/07/2008 22:46, Jean-Francois Ortolo a écrit :
>>
D'où vient l'erreur ? ;)
Excellente question, à laquelle tu es pour le moment le seul à pouvoir
répondre. Commence par les trois questions ci-dessus ($send incorrect,
$var incorrect ou traitement incorrect).
Cordialement,
Bonjour Monsieur
Je suis en train de mettre dans des fichiers "avant.htm" et
"apres.htm", les contenus bruts de var[$i] et decode($var[$i])
Je n'ai plus qu'à lancer le script.
Je pourrai consulter ces fichiers, pour savoir les contenus exacts de
$var[$i], et dans quelle mesure le décodage a un impact sur les données.
Je vous tiens au courant.
En ce qui concerne le "rn" à la fin des lignes des pages html, je
n'étais pas sûr de cela. Au cas où il puisse y avoir un simple saut de
ligne, ne serait-ce qu'un seule fois, j'aurais bien des problèmes avec
explode("rn", $send)
La raison pour laquelle j'utilise un indice numérique, est que je
peux incrémenter cet indice comme je veux à l'intérieur de la boucle de
lecture, pour les besoins du traitement. Il me semble que je ne le
pourrais pas avec une boucle foreach().
Merci beaucoup pour vos conseils.
Bien à vous.
Amicalement.
Jean-François Ortolo
--
Visitez mon site gratuit donnant des Statistiques,
des Pronostics et des Historiques Graphiques
sur les Courses de Chevaux:
http://www.ortolojf-courses.com/
Le 22/07/2008 22:46, Jean-Francois Ortolo a écrit :
>>
D'où vient l'erreur ? ;)
Excellente question, à laquelle tu es pour le moment le seul à pouvoir répondre. Commence par les trois questions ci-dessus ($send incorrect, $var incorrect ou traitement incorrect).
Cordialement,
Bonjour Monsieur
Je suis en train de mettre dans des fichiers "avant.htm" et "apres.htm", les contenus bruts de var[$i] et decode($var[$i])
Je n'ai plus qu'à lancer le script.
Je pourrai consulter ces fichiers, pour savoir les contenus exacts de $var[$i], et dans quelle mesure le décodage a un impact sur les données.
Je vous tiens au courant.
En ce qui concerne le "rn" à la fin des lignes des pages html, je n'étais pas sûr de cela. Au cas où il puisse y avoir un simple saut de ligne, ne serait-ce qu'un seule fois, j'aurais bien des problèmes avec explode("rn", $send)
La raison pour laquelle j'utilise un indice numérique, est que je peux incrémenter cet indice comme je veux à l'intérieur de la boucle de lecture, pour les besoins du traitement. Il me semble que je ne le pourrais pas avec une boucle foreach().
Merci beaucoup pour vos conseils.
Bien à vous.
Amicalement.
Jean-François Ortolo
-- Visitez mon site gratuit donnant des Statistiques, des Pronostics et des Historiques Graphiques sur les Courses de Chevaux: http://www.ortolojf-courses.com/
Olivier Miakinen
Le 23/07/2008 10:59, Jean-Francois Ortolo a écrit :
[...]
En ce qui concerne le "rn" à la fin des lignes des pages html, je n'étais pas sûr de cela. Au cas où il puisse y avoir un simple saut de ligne, ne serait-ce qu'un seule fois, j'aurais bien des problèmes avec explode("rn", $send)
Tous les protocoles Internet en mode texte imposent des fins de ligne en CR+LF (et interdisent CR seul et LF seul, quoique certains autorisent CR+NUL dans certains cas très restreints).
La raison pour laquelle j'utilise un indice numérique, est que je peux incrémenter cet indice comme je veux à l'intérieur de la boucle de lecture, pour les besoins du traitement. Il me semble que je ne le pourrais pas avec une boucle foreach().
En effet. C'est peut-être possible en mélangeant each et foreach, mais même si c'était le cas je le déconseillerais pour des raisons de lisibilité.
Au fait, je confirme que boucler de 0 à (count($var) - 1) comme tu le fais est parfaitement correct.
Cordialement, -- Olivier Miakinen
Le 23/07/2008 10:59, Jean-Francois Ortolo a écrit :
[...]
En ce qui concerne le "rn" à la fin des lignes des pages html, je
n'étais pas sûr de cela. Au cas où il puisse y avoir un simple saut de
ligne, ne serait-ce qu'un seule fois, j'aurais bien des problèmes avec
explode("rn", $send)
Tous les protocoles Internet en mode texte imposent des fins de ligne
en CR+LF (et interdisent CR seul et LF seul, quoique certains autorisent
CR+NUL dans certains cas très restreints).
La raison pour laquelle j'utilise un indice numérique, est que je
peux incrémenter cet indice comme je veux à l'intérieur de la boucle de
lecture, pour les besoins du traitement. Il me semble que je ne le
pourrais pas avec une boucle foreach().
En effet. C'est peut-être possible en mélangeant each et foreach,
mais même si c'était le cas je le déconseillerais pour des raisons
de lisibilité.
Au fait, je confirme que boucler de 0 à (count($var) - 1) comme tu le
fais est parfaitement correct.
Le 23/07/2008 10:59, Jean-Francois Ortolo a écrit :
[...]
En ce qui concerne le "rn" à la fin des lignes des pages html, je n'étais pas sûr de cela. Au cas où il puisse y avoir un simple saut de ligne, ne serait-ce qu'un seule fois, j'aurais bien des problèmes avec explode("rn", $send)
Tous les protocoles Internet en mode texte imposent des fins de ligne en CR+LF (et interdisent CR seul et LF seul, quoique certains autorisent CR+NUL dans certains cas très restreints).
La raison pour laquelle j'utilise un indice numérique, est que je peux incrémenter cet indice comme je veux à l'intérieur de la boucle de lecture, pour les besoins du traitement. Il me semble que je ne le pourrais pas avec une boucle foreach().
En effet. C'est peut-être possible en mélangeant each et foreach, mais même si c'était le cas je le déconseillerais pour des raisons de lisibilité.
Au fait, je confirme que boucler de 0 à (count($var) - 1) comme tu le fais est parfaitement correct.
Cordialement, -- Olivier Miakinen
Jean-Francois Ortolo
Bonjour Monsieur
En fait, les données n'étaient bel et bien pas téléchargées du tout, ceci de manière aléatoire, par suite de la surcharge du serveur.
Ce que je ne m'explique toujours pas, c'est que le timeout réel est bien inférieur à 5 minutes, qui n'est que le timeout du fsockopen(), qui fonctionne lui, alors que le timeout théorique du streaming est bien égal à 50 minutes.
En tout cas, le problème est résolu, car je répète les chargements jusqu'à ce que la variable réceptrice ait une longueur minimale ( au moins 5000 octets ). Avec ce hack, j'ai toutes les données, au prix d'un temps d'attente parfois assez long.
J'ai noté jusqu'à 5 essais de chargement consécutifs pour la même url, dont le dernier réussi.
Je m'attendais, compte tenu du caractère aléatoire du problème, à ce que ce soit un problème aléatoire de surcharge du serveur, et donc d'avoir la possibilité de charger les données après un certain nombre d'essais. Mais pffoouuu... ;)
Donc, problème résolu.
Merci beaucoup de vos conseils.
Bien à vous.
Amicalement.
Jean-François Ortolo
-- Visitez mon site gratuit donnant des Statistiques, des Pronostics et des Historiques Graphiques sur les Courses de Chevaux: http://www.ortolojf-courses.com/
Bonjour Monsieur
En fait, les données n'étaient bel et bien pas téléchargées du tout,
ceci de manière aléatoire, par suite de la surcharge du serveur.
Ce que je ne m'explique toujours pas, c'est que le timeout réel est
bien inférieur à 5 minutes, qui n'est que le timeout du fsockopen(), qui
fonctionne lui, alors que le timeout théorique du streaming est bien
égal à 50 minutes.
En tout cas, le problème est résolu, car je répète les chargements
jusqu'à ce que la variable réceptrice ait une longueur minimale ( au
moins 5000 octets ). Avec ce hack, j'ai toutes les données, au prix d'un
temps d'attente parfois assez long.
J'ai noté jusqu'à 5 essais de chargement consécutifs pour la même
url, dont le dernier réussi.
Je m'attendais, compte tenu du caractère aléatoire du problème, à ce
que ce soit un problème aléatoire de surcharge du serveur, et donc
d'avoir la possibilité de charger les données après un certain nombre
d'essais. Mais pffoouuu... ;)
Donc, problème résolu.
Merci beaucoup de vos conseils.
Bien à vous.
Amicalement.
Jean-François Ortolo
--
Visitez mon site gratuit donnant des Statistiques,
des Pronostics et des Historiques Graphiques
sur les Courses de Chevaux:
http://www.ortolojf-courses.com/
En fait, les données n'étaient bel et bien pas téléchargées du tout, ceci de manière aléatoire, par suite de la surcharge du serveur.
Ce que je ne m'explique toujours pas, c'est que le timeout réel est bien inférieur à 5 minutes, qui n'est que le timeout du fsockopen(), qui fonctionne lui, alors que le timeout théorique du streaming est bien égal à 50 minutes.
En tout cas, le problème est résolu, car je répète les chargements jusqu'à ce que la variable réceptrice ait une longueur minimale ( au moins 5000 octets ). Avec ce hack, j'ai toutes les données, au prix d'un temps d'attente parfois assez long.
J'ai noté jusqu'à 5 essais de chargement consécutifs pour la même url, dont le dernier réussi.
Je m'attendais, compte tenu du caractère aléatoire du problème, à ce que ce soit un problème aléatoire de surcharge du serveur, et donc d'avoir la possibilité de charger les données après un certain nombre d'essais. Mais pffoouuu... ;)
Donc, problème résolu.
Merci beaucoup de vos conseils.
Bien à vous.
Amicalement.
Jean-François Ortolo
-- Visitez mon site gratuit donnant des Statistiques, des Pronostics et des Historiques Graphiques sur les Courses de Chevaux: http://www.ortolojf-courses.com/
Thierry B\.
--{ Olivier Miakinen a plopé ceci: }--
Tous les protocoles Internet en mode texte imposent des fins de ligne en CR+LF (et interdisent CR seul et LF seul, quoique certains autorisent CR+NUL dans certains cas très restreints).
Sur les protocoles, oui, mais je ne pense pas que cela concerne les contenus du genre page html.
-- <Eva> Vous, les geek, vous avez vraiment une case en moins... <Dieu> C'est pas qu'on a une case en moins, c'est juste qu'on compte à partir de zéro.
--{ Olivier Miakinen a plopé ceci: }--
Tous les protocoles Internet en mode texte imposent des fins de ligne
en CR+LF (et interdisent CR seul et LF seul, quoique certains autorisent
CR+NUL dans certains cas très restreints).
Sur les protocoles, oui, mais je ne pense pas que cela concerne
les contenus du genre page html.
--
<Eva> Vous, les geek, vous avez vraiment une case en moins...
<Dieu> C'est pas qu'on a une case en moins, c'est juste qu'on compte
à partir de zéro.
Tous les protocoles Internet en mode texte imposent des fins de ligne en CR+LF (et interdisent CR seul et LF seul, quoique certains autorisent CR+NUL dans certains cas très restreints).
Sur les protocoles, oui, mais je ne pense pas que cela concerne les contenus du genre page html.
-- <Eva> Vous, les geek, vous avez vraiment une case en moins... <Dieu> C'est pas qu'on a une case en moins, c'est juste qu'on compte à partir de zéro.
Olivier Miakinen
Le 23/07/2008 22:01, Thierry B. a écrit :
--{ Olivier Miakinen a plopé ceci: }--
Tous les protocoles Internet en mode texte imposent des fins de ligne en CR+LF (et interdisent CR seul et LF seul, quoique certains autorisent CR+NUL dans certains cas très restreints).
Sur les protocoles, oui, mais je ne pense pas que cela concerne les contenus du genre page html.
C'est vrai pour HTML seul, par exemple pour une page HTML stockée dans le système de fichiers local et récupérée par une url de type file://. Mais là, c'est une page HTML ayant transité sur le réseau via le protocole HTTP, et d'ailleurs la détection de la fin des entêtes se fait par « strpos($send, "rnrn") ».
D'un autre côté, rien ne nous empêche de mettre ceinture et bretelles pour le cas où le serveur HTTP ferait mal son boulot, mais je doute que ce soit nécessaire.
Le 23/07/2008 22:01, Thierry B. a écrit :
--{ Olivier Miakinen a plopé ceci: }--
Tous les protocoles Internet en mode texte imposent des fins de ligne
en CR+LF (et interdisent CR seul et LF seul, quoique certains autorisent
CR+NUL dans certains cas très restreints).
Sur les protocoles, oui, mais je ne pense pas que cela concerne
les contenus du genre page html.
C'est vrai pour HTML seul, par exemple pour une page HTML stockée dans
le système de fichiers local et récupérée par une url de type file://.
Mais là, c'est une page HTML ayant transité sur le réseau via le
protocole HTTP, et d'ailleurs la détection de la fin des entêtes se
fait par « strpos($send, "rnrn") ».
D'un autre côté, rien ne nous empêche de mettre ceinture et bretelles
pour le cas où le serveur HTTP ferait mal son boulot, mais je doute que
ce soit nécessaire.
Tous les protocoles Internet en mode texte imposent des fins de ligne en CR+LF (et interdisent CR seul et LF seul, quoique certains autorisent CR+NUL dans certains cas très restreints).
Sur les protocoles, oui, mais je ne pense pas que cela concerne les contenus du genre page html.
C'est vrai pour HTML seul, par exemple pour une page HTML stockée dans le système de fichiers local et récupérée par une url de type file://. Mais là, c'est une page HTML ayant transité sur le réseau via le protocole HTTP, et d'ailleurs la détection de la fin des entêtes se fait par « strpos($send, "rnrn") ».
D'un autre côté, rien ne nous empêche de mettre ceinture et bretelles pour le cas où le serveur HTTP ferait mal son boulot, mais je doute que ce soit nécessaire.
Thierry B\.
--{ Olivier Miakinen a plopé ceci: }--
Sur les protocoles, oui, mais je ne pense pas que cela concerne les contenus du genre page html.
C'est vrai pour HTML seul, par exemple pour une page HTML stockée dans le système de fichiers local et récupérée par une url de type file://. Mais là, c'est une page HTML ayant transité sur le réseau via le protocole HTTP, et d'ailleurs la détection de la fin des entêtes se fait par « strpos($send, "rnrn") ».
Et une fois que le header est envoyé, le serveur web envoie le contenu du fichier.html sans le modifier. En tout cas, chez moi, c'est comme ça que ça se passe. Pas de rajout de <CR>... Ceci dit, il y a peut-être des serveurs http qui font autrement, mais j'en doute fort.
-- Q : If someone has the code in python for a buffer overflow, please post it. A : Python does not support buffer overflows, sorry. --{ comp.lang.python }--
--{ Olivier Miakinen a plopé ceci: }--
Sur les protocoles, oui, mais je ne pense pas que cela concerne
les contenus du genre page html.
C'est vrai pour HTML seul, par exemple pour une page HTML stockée dans
le système de fichiers local et récupérée par une url de type file://.
Mais là, c'est une page HTML ayant transité sur le réseau via le
protocole HTTP, et d'ailleurs la détection de la fin des entêtes se
fait par « strpos($send, "rnrn") ».
Et une fois que le header est envoyé, le serveur web envoie le
contenu du fichier.html sans le modifier. En tout cas, chez moi,
c'est comme ça que ça se passe. Pas de rajout de <CR>... Ceci dit,
il y a peut-être des serveurs http qui font autrement, mais j'en
doute fort.
--
Q : If someone has the code in python for a buffer overflow, please post it.
A : Python does not support buffer overflows, sorry.
--{ comp.lang.python }--
Sur les protocoles, oui, mais je ne pense pas que cela concerne les contenus du genre page html.
C'est vrai pour HTML seul, par exemple pour une page HTML stockée dans le système de fichiers local et récupérée par une url de type file://. Mais là, c'est une page HTML ayant transité sur le réseau via le protocole HTTP, et d'ailleurs la détection de la fin des entêtes se fait par « strpos($send, "rnrn") ».
Et une fois que le header est envoyé, le serveur web envoie le contenu du fichier.html sans le modifier. En tout cas, chez moi, c'est comme ça que ça se passe. Pas de rajout de <CR>... Ceci dit, il y a peut-être des serveurs http qui font autrement, mais j'en doute fort.
-- Q : If someone has the code in python for a buffer overflow, please post it. A : Python does not support buffer overflows, sorry. --{ comp.lang.python }--
Olivier Miakinen
Le 24/07/2008 19:06, Thierry B. a écrit :
Et une fois que le header est envoyé, le serveur web envoie le contenu du fichier.html sans le modifier. En tout cas, chez moi, c'est comme ça que ça se passe. Pas de rajout de <CR>...
D'accord, et merci pour l'info.
Désolé, je n'avais pas fait l'essai avant de raconter n'importe quoi.
Le 24/07/2008 19:06, Thierry B. a écrit :
Et une fois que le header est envoyé, le serveur web envoie le
contenu du fichier.html sans le modifier. En tout cas, chez moi,
c'est comme ça que ça se passe. Pas de rajout de <CR>...
D'accord, et merci pour l'info.
Désolé, je n'avais pas fait l'essai avant de raconter n'importe quoi.
Et une fois que le header est envoyé, le serveur web envoie le contenu du fichier.html sans le modifier. En tout cas, chez moi, c'est comme ça que ça se passe. Pas de rajout de <CR>...
D'accord, et merci pour l'info.
Désolé, je n'avais pas fait l'essai avant de raconter n'importe quoi.
