Kioob

Ton site est chez OVH et j'execute mon telnet (via IP) depuis un autre serveur OVH : à aucun moment je ne passe par quoi que ce soit en Chine. Si le script est vraiment rapide, alors il y a un autre élément qui intervient entre Apache et PHP pour bloquer le tout... mod_gzip peut être ? Essaye de regarder dans "/tmp" s'il n'y aurait pas quelques milliers de fichiers en trop (ce qui peut arriver quand mod_gzip part en sucette), ou bien désactive directement le module pour tester.

mm "chez moi ça marche" :S Mis à part quelques soucis avec les données importées depuis Ajax je n'ai pas ce genre de problèmes. Aurais tu une URL d'exemple ? Edit : une solution serait d'utiliser htmlentities (en précisant qu'il s'agit d'UTF-8). Même s'il là de "contourner" le problème.

Hello, s'il n'est pas déjà activé un "ignore_user_abort()" est peut-être nécessaire afin d'assurer l'exécution du unlink(), non ?

A mon avis la réponse se trouve dans ton script... Là tout de suite c'est très rapide, aucun ralentissement. N'as tu pas un élément dans le script de ta home page qui fait un appel externe ? Et/ou un accès système ? (session ou résolution DNS par exemple). PS : pour moi rien à voir avec l'extension ou les DNS du coup, via telnet je fais la connexion directement sur l'IP.

les chemins que tu indiques à file_put_contents() et à readfile() semblent différent... ça a peu de chance de fonctionner. De plus ici tu cherches à envoyer directement le contenu au navigateur, donc pas besoin de l'écrire dans un fichier, un simple "echo" suffira. De manière générale, lis les messages d'erreur que PHP retourne... c'est très souvent utile.

Hello, est ce que l'url_fopen est activé ? (à vérifier depuis un phpinfo(); ) S'il est actif, un simple "copy( $img_dist, $img_local );" suffira.

Hello, pour du full utf8 il faut généralement : - sur toutes les pages un header('Content-type: text/html; charset=UTF-8') ; à moins qu'il soit configuré comme charset par défaut via ton .htacces, mais à vérifier grace à "live headers" ou le developper bar pour voir les entêtes. - en entête de toutes les pages, un meta "content-type" ou tag XML indiquant qu'il s'agit d'UTF8 - coté MySQL généralement il faut indiquer à MySQL que la connexion est en UTF-8 (et ce n'est pas lié à phpmyadmin)... là encore, à mois qu'elle soit configurée de la sorte "par défaut" Ensuite il se peut que le navigateur bascule en mode "iso-8859-1" si le premier "accent" du fichier est en iso-8859-1. J'ai eu le soucis récemment avec un IE6 : un seul caractère de la page était mal encodé, ce qui faisait foirer tout le reste. Sinon personnellement je n'ai jamais réussi à faire enregistrer correctement des valeurs UTF-8 à phpMyAdmin. Toutes les autres interfaces d'accès à MySQL fonctionnent parfaitement, mais phpMyAdmin semble souvent mélanger tout ça (mais peut être que dans mon cas il s'agit d'un soucis de configuration de phpMyAdmin, je ne me suis jamais vraiment penché dessus). Tout ça pour dire que si tes données ont été saisie via phpMyAdmin, elles ne sont peut-être pas encodées comme il faut en base.

Hello, quelle version de PHP utilises tu ? Depuis PHP 5.2 il y a la classe "Zip_Archive" qui est bien pratique pour compresser/décompresser en zip. Sinon un fichier .gz ne suffirait il pas ? C'est quand même beaucoup plus simple : if( $fp = gzopen( 'fichier.gz', 'wb' ) ){ gzwrite( $fp, $contents ); gzclose( $fp ); }

A l'heure actuelle LORI m'indique du 10 secondes pour le "Time to first byte", c'est à dire le temps que ton serveur mette à répondre... avant même que le moindre script JS n'entre en compte donc. Si je rafraîchis la page le délai passe à 5 secondes. En telnet on voit clairement que le script pédale : le telnet se connecte généralement immédiatement (donc Apache répond au quart de tour), mais une simple requete HEAD / HTTP/1.0 va mettre plusieurs secondes à répondre. A noter que si je fais ma requête HEAD sur une image (/jdd/public/images/fw_logo.gif) la réponse est immédiate.

Hello, essaye de remplacer l'index sur statut par un index sur statut+ville (dans cet ordre). Par contre pour le filesort, je pense que tu n'as guère le choix ici... enfin tu peux toujours tenter d'ajouter une troisième colonne à cet index (date_maj) mais je ne suis franchement pas certain que mySQL s'en servirait.

Hello, quels sont les indexes présents sur la table en question ? Et que donne un EXPLAIN de ta requête ? PS : peux tu reformater ton post afin que les requetes soient un peu plus lisibles stp ? Quelques retours à la ligne faciliteraient la lecture.

Je n'ai pas testé ce matin, et ne serai donc pas d'une grande utilité (bien que ça réponde niquel en ce moment, malgré la première latence coté DNS). Toutefois je ne peux que conseiller l'utilisation de plugins dédiés à ce genre de chose : LORI et YSLOW par exemple permettent de relativement bien débugger ce genre de choses. Par exemple là tout de suite LORI m'indique 2.5 secondes pour ta page d'accueil, et YSLOW détaille par : moins de 100ms pour les 4 éléments constituant ta page, et 600ms pour adsense. Je suppose que le reste c'est du DNS. Pour les soucis de DNS, il me semble que Firefox ne met en cache la résolution qu'une minute (je ne sais plus où j'ai lu ça). Après, le cache de l'OS peut intervenir avec des règles qui lui sont propres... vient ensuite parfois le cache du "routeur", ensuite celui du FAI et généralement le "vrai". Bref, les problèmes de lenteur ne sont pas toujours causés par le dernier maillon ; j'ai toujours trouvé les DNS de Free par exemple assez lents.

Hello, ton fichier XML est indiqué comme étant en ISO-8859-1 dans les entêtes HTTP, mais par défaut les parseurs XML travaillent en UTF-8. Je suppose qu'il suffit "juste" ici d'indiquer à ton parseur qu'il s'agit d'ISO. A ce que je comprends de la doc il suffit de modifier la propriété $encoding de ton objet ; mais je n'ai pas essayé. (en fait ça se fait aussi via le constructeur, ce qui est quand même plus propre : http://fr.php.net/manual/en/domdocument.construct.php )

De rien, et bonne soirée à toi aussi

source : Google. hu hu... ton script est en UTF-8 Un peu plus d'info du coté de Wikipedia : http://fr.wikipedia.org/wiki/Marque_d%27ordre_des_octets Ce serait donc ton éditeur qui ajoute (inutilement) cet entête afin d'indiquer que le fichier est en UTF-8... Bref si tu peux, change d'éditeur.

Bah t'avais pas dit qu'ils faisaient exactement la même taille ? Je peux me tromper, mais j'ai l'impression que les deux premiers caractères correspondent à l'entête GZIP ; peux tu donner leur valeur héxadécimale stp ? Edit : non, à priori ce n'est pas du tout ça :/

Le error_reporting change le "niveau de report" des erreurs, là il affiche la plupart des erreurs (par défaut les E_NOTICE ne sont pas affichés), mais il n'affiche pas pour autant les E_STRICT. Je n'ai jamais vu readfile() corrompre un fichier, tu es certain que le chemin que tu indiques en paramètre à la fonction correspond au fichier que tu as transféré par FTP, en mode BINARY ?

Amha readfile() est de loin la plus adaptée ici ; les autres fonctions feront toutes plus ou moins la même chose en moins bien (plus lentement et/ou en consommant plus de mémoire). Si un script minimal avec seulement ça (absolument rien d'autre) ne fonctionne pas, c'est qu'il y a un gros pépin : <?php error_reporting( E_ALL ); header( "Content-Type: application/octet-stream" ); header( "Content-Disposition: attachment; filename=archive.zip" ); header( "Pragma: no-cache" ); header( "Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0" ); header( "Expires: 0" ); readfile( '/chemin/vers/un/fichier.zip' ); Quand tu dis que ça ne donne rien, c'est que la sortie est "vide" ou bien que Windows n'arrive pas à décompresser le fichier obtenu ? Essaye de comparer les deux fichiers en mode "binaire" (UltraEdit fait ça très bien), les différences devraient être marquantes. EDIT : euh... un fichier binaire n'a absolument pas besoin d'une conversion Windows/Mac/Unix. Et readfile() ne fait pas de conversion non plus. Donc à moins que la source ait été uploadée de manière corrompue en ASCII via FTP, il n'y aucune raison de vouloir "convertir" un ZIP.

Le soucis en spécifiant soit même le "content-length" c'est qu'il peut être erroné (par exemple si un ob_gzhandler se déclenche derrière, même si ce n'est pas le cas ici), et ainsi causer une "corruption" du canal en cas de KeepAlive. Mais pour en revenir à ton problème, je ne vois pas du tout de quoi ça pourrait venir. readfile() est heureusement "binary safe", et fonctionne d'habitude très bien, peu importe ce qu'on balance en sortie. EDIT : et en utilisant un comparateur de fichier "binaire", tu notes quoi comme différence ? Il me semble qu'un fichier ZIP contient la date de création ou un truc du genre, le checksum sera donc toujours différent, non ?

Bonsoir, pour ma part je n'enverrais pas le "Content-length" et ferais simplement un readfile après l'envoi des entêtes ; toutefois je ne pense pas que ce soit ce qui pose soucis. De plus, je ne connais pas vraiment les entêtes Content-Description, Content-Transfer-Encoding, t'es certain de ton coup là ? Sinon le transfert tu le fais comment, via un navigateur ?

Fais voir ta "mise en place" alors stp

Hello, en théorie la requête POST à envoyer est POST /http-request-reponse.php et non l'URL complète (d'où l'entête avec Host: monsite.com) ; je suppose que ça joue sur le résultat. De plus, il manque plein de retours chariot dans cette ligne : $HTTP_REQUEST.='Connection: close Accept-Encoding: gzip Content-Type: application/x-www-form-urlencoded Content-Length: '.strlen($POST_DATA)."\n\n"; Et pour débugger plus facilement dans ton script de test tu devrais peut-être faire un var_dump( $_POST ) pour voir exactement le contenu du tableau, non ? Sinon dans l'élan, je te déconseille d'envoyer l'entête Accept-Encoding: gzip : si ton serveur gérait la compression, tu te retrouverais avec un contenu difficile à traiter, surtout avec la version 1.1 d'HTTP. EDIT : pour l'aspect sécurité, tout dépend du script en question. Si cela déclenche un traitement faisant des modifications, oui, il vaut mieux le laisser en POST pour éviter les "injections XSS". Mais mis à part ce cas, ça ne change rien non, la méthode POST n'apportant guère plus de sécurité que la méthode GET.

Effectivement ton chown ne cassera rien, j'avais lu trop vite désolé (j'avais cru que tu mettais tout sous l'utilisateur Apache, ce qui aurait réglé son problème de script). ProFTPd (mais peu importe le soft), accède actuellement à ce dossier via le compte Unix vt-boutique-net et hérite donc de tous les droits qui vont avec ; c'est à dire que les fichiers et dossiers sont créés avec comme propriétaire vt-boutique-net. Pour que PHP ait les droits d'écriture, il faut "juste" qu'il colle un 0777 sur les dossiers dans les lesquels il veut créer des fichiers... c'est crade et complètement insécurisé, mais avec Plesk guère d'autres solutions. Et pour les fichiers à modifier via PHP, c'est évidement du 0666. Donc vu les droits nécessaires "à la Windows", je pense qu'il ne faut surtout pas affecter ça à l'aveugle sur toute son arborescence. Surtout qu'il faudra recommencer pour chaque dossier/fichier créé par FTP... En passant, à moins que Plesk ait furieusement changé son mode de fonctionnement, il n'y a absolument aucun chroot de fait coté Apache/PHP. C'est un bète PHP en module Apache, avec pour seule sécurité le safe_mode+open_basedir. PS : PureFTPd fonctionne en standard avec des comptes UNIX, mais là n'est pas le problème.

Hello, perso je me demande pourquoi tu gardes encore Plesk : visiblement il ne te convient pas du tout puisque tu veux un système "personnalisable".

Soit tu modifies le Umask comme je t'ai indiqué ci dessus, soit il te faut changer de compte Unix pour chaque domaine. Et donc en plus de changer le propriétaire de tous les fichiers du site, il faut revoir toute la configuration du serveur FTP, et c'est géré par Plesk... donc dès que tu retoucheras à Plesk, il ré-écrira par dessus. Sans oublier les éventuels effets de bord, tels que Webalizer, ou les crons qui auront de très grandes chances de ne plus fonctionner. Si tu ne veux plus utiliser Plesk, il faut repartir sur une installation sans Plesk... mais bidouiller à l'aveugle n'amènera rien de bon.