Kioob

Hello, essaye d'enlever le Content-length éventuellement. Pour peu que la compression soit activée, l'info est fausse. Sinon plusieurs trucs me gênent : - pourquoi utilises tu une adresse en "http://" pour pointer l'image local ? Tu cherches à saturer le plus vite possible ton serveur Apache ? - si je remplace ce paramètre filename par le nom de ton fichier de config, je vais aussi récupérer tes identifiants d'accès MySQL, rigolo non ? - pourquoi diable désactiver toute mise en cache ? Surtout pour un site de fond d'écran où la bande passante est souvent un problème. - sur tes entêtes, tu mets un domaine "no-cache" et la ligne d'après tu le remplaces par un domaine "public"... tu veux lequel en fait ?

re pour le coup je n'ai pas trop d'idée... ça me semble quand même étonnant tout ça... mais j'ai la flemme de regarder dans la RFC pour voir si c'est "normal". PS : attention toutefois, à ma connaissance urlencode() ne sert qu'à simuler les requêtes POST. Dans les autres cas c'est rawurlencode() qu'il faut utiliser, même si la déférence est mince (je crois que seul l'espace change). En même temps ça fait longtemps que je n'ai pas regardé ça, je peux me tromper

Hello, fais donc voir ta règle de rewriting stp... à mon avis l'erreur vient de là, le rawurlencode() servant justement à éviter ce genre de couac.

Le code que je t'ai donné n'affiche pas d'erreur, mais le contenu de ta variable et le résultat de la fonction. Et comme je le soupçonnais, on peut clairement voir que c'est le chemin de ton fichier qui est faux : /home/www/lesite/www/test/newsimg/.png. Bref le chmod semble parfaitement fonctionner (d'où le "true" en réponse), sauf qu'il est fait sur le fichier ".png" qui est un fichier caché et que tu ne vois probablement pas via FTP.

Hello, je vois au moins 3 possibilités : 1) utiliser l'extension CURL de PHP pour rapatrier le fichier en question (puis lui faire faire ton getimagesize() ou tout autre traitement). Cette une extension qu'on retrouve souvent et qui gère très bien de nombreux protocoles, dont HTTP. 2) développer ton propre client HTTP qui gérerait les redirections 3) utiliser une des nombreuses classes déjà faites à la place du n°2. Le principe sera de toutes façons le même : télécharger l'image en local pour la traiter. On doit au moins retrouver ça dans PEAR et dans le Zend Framework si tu veux t'en inspirer. PS : si tu te sens d'attaque pour le n°2, il y a sûrement moyen de développer directement un flux et ainsi éviter la phase de stockage local temporaire.

Je me répète, mais vérifie déjà par FTP si le chmod() est bien effectué... Le débugage, ça se fait par étape. *) par FTP, vérifie que le fichier soit bien uploadé dans le dossier que tu souhaites. Sa date est elle bien mise à jour lors de l'upload ? *) par FTP toujours, tu dis que tu me confirmes que tu vois 0600 comme droits par défaut quand tu ne fais pas ton chmod ? *) quand tu fais un chmod 0644 (via PHP hein) et que tu vérifies par FTP derrière, tu vois quels droits ? 0600 toujours, ou bien un truc farfelu ? *) as tu vérifié le contenu de ta variable ? *) as tu activé l'affichage des erreurs PHP ? *) as tu regardé quels droits le serveur FTP attribue t'il par défauts aux images, afin de savoir quels droits tu dois mettre ? Si tu n'as pas eu d'erreur là dessus c'est que leur affichage est désactivé... parce que tenter de modifier des droits d'accès via HTTP, ça a peut de chance d'arriver à quoi que ce soit. Remplace ton bloc "chmod" par ça : error_reporting( E_ALL ); ini_set( 'display_errors', true ); var_dump( $fichier1b ); var_dump( chmod( $fichier1b, 0644) ); exit;

J'ai laissé tomber le plugin Eclipse en tous cas... finalement il n'était pas spécialement utile, et comme le dossier de travail est sur un lecteur samba le plugin posait plus de problèmes qu'autre chose. Bref, coté client sur les postes Windows on a juste du Tortoise SVN, et ça va déjà très bien. Coté serveur, bah... on a juste le "repository classique". Pas besoin de l'intégration à Apache, ou autres trucs du genre... Il s'agit juste de pouvoir bosser à plusieurs, pas de rendre quoi que ce soit publique non ? Donc SSH + Subversion et c'est parti.

Bonjour, il me semble que chez Celeonet c'est du suexec+fastcgi oui. Le premier truc à faire à mon avis est de regarder via FTP si le chmod est bien effectué. J'ai un sérieux doute quand à la construction de ta variable $fichier1b. Si le chmod ne passe pas, afficher les erreurs de PHP pourrait être utile... Sinon les droits 0644 sont amplement suffisant pour qu'Apache ait accès aux images... ainsi que les autres hébergés. Pas la peine de prendre plus de risque. Avec SuExec l'idéal serait soit 0640 soit 0604 selon la configuration utilisée par l'hébergeur. Ca aussi tu peux le vérifier par FTP : envoie une image par FTP et regarde ses droits, ils sont certainement "bons" d'origine.

Hello, il y a plusieurs solutions : - transmettre les infos à un cron qui lui tournera en root : l'inconvénient, c'est que du coup le traitement est différé - faire tourner un démon en root avec lequel ton script communiquera via un socket par exemple... mais ça me semble complexe à mettre en place pour si peu. - utiliser un script shell spécifique auquel tu attribueras le "suid" de root. Mais à la moindre faille dans ce script, ça peut être la cata coté sécurité. - utiliser sudo et autoriser "www-data" à lancer "iptables" : c'est pas terrible non plus, à moins que tu n'ais qu'un seul site sur le serveur, pas de phpMyAdmin, pas de webmail, pas de phpBB, ou autre script risquant d'être exploité (bien que le risque soit quand même assez limité). A moins d'en profiter pour passer PHP en SuExec + FastCGI, et que chaque site soit isolé sur son propre compte unix. Là comme ça, je ne vois pas d'autre alternative en tous cas. Mais peut-être que quelqu'un en verra d'autre.

Le "DISTINCT" ne sert à rien ici vu que tu as déjà un "GROUP BY". Et du coup ormis le "ORDER" la requête est la même qu'avant...

Hello, à priori CVS ne gère pas "de base" les fichiers binaires ; as tu vérifié ? En tous cas avec SVN c'est le genre de pépin que je n'ai jamais eu.

Si tu veux tous les ID, dans ce cas ce serait : select record, max( end_date ) as maxDate from log_cb group by record

Hello, select max( end_date ) as maxDate from log_cb where record = 171 non ?

Avec 4'000 vu par jour, c'est clair qu'on a pas à se poser ce genre de questions... Mais avec 400'000 ça peut. ams51 : yep c'est bien pour ça que je n'utilise pas de cache de rendu. J'ai un client qui avait pas loin de 20Go de fichiers servant à son cache de rendu... le serveur passe plus de temps à écrire sur le disque qu'autre chose.

Ca, ça dépend de la taille du site... arrivé à un certain trafic, quand on loue déjà plusieurs serveurs à 500 HT/mois chez OVH, il faut commencer à se poser ce genre de questions Il est évidement que si un "SP Mini" suffit pour le site, ce n'est pas non plus la peine de se prendre le chou avec des techniques "complexes".

Oui donc méthode "classique" (que j'utilise également hein), le soucis étant que dans ces cas là tu utilises PHP "pour rien".... et justement c'est très lent. Essaye de faire un simple benchmark sur un fichier HTML statique puis sur un fichier PHP contenant uniquement ce code HTML (sans le moindre tag PHP) ; la différence est énorme.

Mais le cookie de session, il a quelle tronche quand tu regardes les entêtes ? (Information => View Response Headers) Parce que s'il n'est pas conservé quand tu passes du back au front, faut pas chercher plus loin ça ne peut pas fonctionner sans ça.

Là j'avoue que je ne vois pas du tout ce que tu veux dire. Le principe est le suivant : imaginons que l'internaute demande au serveur la page /bidule/truc.html . Tu as deux cas : - elle n'existe pas : le serveur déclenche une erreur 404, et par configuration tu peux lui demander d'appeler un script PHP. Si ce script PHP estime que "bidule/truc.html" correspond effectivement à un contenu, il va créer le fichier /bidule/truc.html et retourner un code 200 ainsi que le contenu de ce fichier. - elle existe : le serveur retourne directement cette page, tout en gérant comme il se doit les divers entêtes HTTP et la compression à la volée. C'est plus complexe à mettre en place, n'est vraiment pas adapté aux sites très dynamiques de type forum ou personnalisés en fonction de l'utilisateur, mais le gain de performances n'a vraiment rien à voir avec ce qu'on peut obtenir en se basant uniquement sur PHP. Mais le but ici est clairement les performances, pas de contourner un problème Apache, PHP ou encore MySQL. Pour masquer les problèmes de MySQL, j'utilise un simple cache de données. Pour contourner les problèmes de PHP, j'ai FCGID qui envoi une page 500 personnalisée. Pour contourner les problèmes d'Apache, j'ai NginX en front qui envoi une page 503 personnalisée.

Une possibilité dans ce cas serait que sur le front le cookie soit placé dans "/", et sur le back uniquement quand "/back". Ce qui expliquerait que le passage fonctionne dans un sens mais pas dans l'autre. Et ça, tu peux facilement le vérifier directement avec les extensions de Firefox (la developperbar typiquement). PS : chez nous aussi le passage en prod se fait via une interface web spécifique, qui lance le rsync "qui-va-bien", mais ça n'empêche pas d'y livrer n'importe quoi si on veut

Et tu n'as pas accès tout simplement à ini_get ? :S Et le dossier de stockage des sessions (s'il s'agit d'un stockage fichier) ? Sinon le backoffice est sur le même sous domaine ? Y a t'il un changement de protocole http / https entre le front et le back ? => il se pourrait que ce soit tout simplement les paramètres du cookie de session qui soient différents. Comme pour tout je pense qu'il "suffit" de procéder par étape : - déjà voir si le cookie de session est bien conservé lorsque l'on passe du front au back et vice versa - puis voir si un après un session_start() le contenu a été conservé ou non Sinon est ce le même "session handler" sur les deux ? Et est ce le même compte Unix pour les deux ?

Ce serait donc un cache de "rendu". Si tu veux le faire toi même, c'est à coup d'ob_start() / ob_get_contents() / file_flush_contents pour l'écriture, puis readfile() pour la lecture. Un simple filemtime() servira à vérifier l'existence et la durée de cache. Pour le coté "modification depuis la dernière visite", en fait le navigateur envoi le contenu du dernier "LastModified" qu'il a reçu. Il te suffit de comparer cet entête avec la date de ton fichier de cache, et basta. Pour ce qui est de la compression, il n'y a rien de spécial à faire non... Ormis de penser à la désactiver en cas de réponse 304 (à cause d'un "bug" de PHP). PS : ça c'est pour la version "full" PHP. L'idéal étant de générer un fichier 100% statique, et de ne faire appel à PHP qu'en cas de d'erreur 404.

Hello, j'ai du mal à comprendre exactement ce qui pose soucis dans tes questions, mais je vais tenter de ne pas trop répondre à coté de la plaque Déjà il faut bien faire la distinction entre les différents cache. Coté PHP les 3 principaux qu'on croise sont : - le cache du navigateur (géré à coup de "ETag", de "LastModified" et de "Expires") : cela permet de faire quelques économies de ressource coté serveur et améliore grandement la "sensation de vitesse" pour l'internaute. La page n'est pas re-téléchargée, et généralement pas réinterprétée non plus. Dans le cas de Firefox il peut même être possible de ne pas avoir à ré-exécuter le JS. D'un point de vue utilisateur, c'est pour moi le cache le plus efficace. - le cache de données (qui consiste à stocker le résultat d'un traitement sous forme "serialisée" ; typiquement une grosse requête). L'avantage c'est qu'il est très souple/modulaire et peut être intégré à tous les types de page de manière plus ou moins complexe. En solution toute prête, il me semble que "Cache_Lite" fait ça. - le cache de rendu (c'est à dire le code HTML généré par les scripts). C'est de loin le moins souple mais le plus efficace : souvent il se base uniquement sur l'URL pour générer une "clé" et durant N secondes le contenu d'un fichier statique sera directement retourné à l'utilisateur plutôt que d'exécuter les traitements habituels. En solution toute prête, il y aurait JPCache qui faisait ça, et sa soit disant "évolution" QuickCache. Généralement les caches de rendus se chargent aussi de gérer le cache du navigateur, mais ça n'a rien d'obligatoire. Sur mes sites par exemple je gère systématiquement le cache du navigateur, et sur certains sites/pages j'utilise un cache de données.... mais jamais de cache de rendu par exemple. Donc toi, tu cherches quelle solution au juste ? Pour ta première question, il s'agit de gérer correctement le cache navigateur.... et pour les scripts PHP, ça ne se fait pas de manière automatique. C'est donc à tes scripts de prendre ça en charge. Dès lors que tu as la date de dernière modification c'est très simple à mettre en place (ça se fait en 3/4 lignes de code) mais le plus difficile est d'obtenir cette info justement. Les caches de rendus se basent alors sur l'heure de création du fichier de cache pour gérer le LastModified... et parfois sur le contenu de ce fichier de cache pour générer un checksum et ainsi gérer l'entête ETag. Pour ce qui est de la compression, elle n'intervient aucunement là dedans... Ormis éventuellement JPCache qui stockait la version compressée de la page afin de ne pas avoir à recompresser systématiquement. Perso je préfère laisser cette tâche à la compression interne de PHP (zlib.output_compression) qui fait ça très bien et sans devoir attendre la fin de la page. Pour ce qui est des "exceptions", c'est faisable dans tous les cas.

Hello, convertir les dates en chaine pour pouvoir les sélectionner à coup de "like", c'est assez original je trouve, mais ça limite sûrement l'utilisation des indexes. Je tenterais plutôt au choix : where date( tonChampDateTime ) = '2008-09-16' ou : where tonChampDateTime >= '2008-09-16' and tonChampDateTime < '2008-09-16' + interval 1 day Je ne sais pas dans quel situation MySQL utilise mieux les index... la première solution étant certainement plus proche. Dans tous les cas tester ces requêtes à coup d'EXPLAIN sera toujours utile.

Enfin il y a installation et installation... sans savoir ce qu'inclus exactement cette phase chez eux, difficile de se prononcer. Perso ce tarif ne me choque pas, même si j'ose espérer que le résultat est très loin d'une installation "classique" made in OVH par exemple.

En même temps si c'est pour PDO, PHP 5.2 suffit non ?