Kioob

Au 27 septembre : puis 01 octobre :

Ah bah dans ce cas c'est un tout autre problème oui... il y aurait une autre "couche" qui viendrait ajouter sa compression GZIP à tord sur ces requêtes 304 ?? Peux tu désactiver tes options Apache concernant le module DEFLATE, pour voir ?

Es tu certain de bien avoir fait la modification ? Si je teste avec mon script maison (cf plus bas), l'entête GZIP en trop est toujours présent au milieu du flux HTTP. <?php $sk = fsockopen('www.last-video.com', 80); $headers = array( 'GET /category/cinema HTTP/1.1', 'Host: www.last-video.com', 'Accept-Encoding: gzip,deflate', 'Keep-Alive: 300', 'Connection: keep-alive', // 'If-Modified-Since: Tue, 21 Aug 2007 13:00:54 GMT', 'If-None-Match: "qcd-3211233437.29771"', ); function sock_send( &$sk, $line ) { echo '> ', $line, PHP_EOL; fputs($sk, $line."\r\n"); } function sock_gets( &$sk ) { $line = fgets($sk, 4096); echo '< ', rtrim($line), PHP_EOL; return $line; } for( $i = 1; $i <=2 ; $i++ ) { echo "Sending request ", $i, PHP_EOL; foreach( $headers as $h ) sock_send($sk, $h); sock_send($sk, ''); echo "Reading headers only (no contents should be send)", PHP_EOL; $numLine = 0; while( !feof($sk) ) { $line = trim(sock_gets($sk)); if( ++$numLine === 1 ){ echo '['.dechex(ord($line{0})).dechex(ord($line{1})).']'.PHP_EOL; } if( $line === '' ) { break; } } } fclose($sk); Note : l'ETag dans la ligne "If-None-Match" est évidement à adapter en fonction du véritable ETag de tes pages (visibles via l'extension LiveHTTPHeaders de Firefox, ou encore l'extension Web Developper). Par exemple là tout de suite ça me retourne ça : On voit clairement lors de la deuxième réponse qu'il y a des caractères "bizarres" en trop avant le "HTTP/1.1 304 Not Modified". Comme indiqué juste en dessus cette ligne commence par les caractères 0x1f8b, ce qui est la signature du GZIP, et c'est ça qui cause tes soucis : QuickCache continue à faire l'encodage gzip sur les réponses 304.

Et bien tu actives à la fois la compression interne à PHP et celle d'Apache, ça fait double emploi, au moins sur les pages PHP. Pour ce qui est des lenteurs constatées, tu n'aurais pas une URL à donner, que je vérifie la présence ou non du bug en question ?

C'est pas au début ou à la fin de la fonction qu'il faut le mettre mais exactement avant ou après le bloc que j'ai indiqué. Il faut absolument que ce soit entre les accolades du if (strstr($foundETag, $myETag)). Et il faut également enlever le "SetEnv nokeepalive" dans le .htaccess oui.

merci mais attention : la désactivation du KeepAlive comme je l'indiquais dans mon premier post est uniquement un moyen rapide de tester qu'il s'agisse bien de la cause du problème. Il ne faut pas laisser le KeepAlive désactivé simplement à cause de ce bug, cela pourrait avoir des impacts non voulus sur la vitesse de navigation de tes visiteurs. Pour ce bug spécifique, la seule solution valable à mon avis est d'ajouter ce "workaround" dans le code comme indiqué ci dessus : c'est la seule solution qui n'a aucun "effet de bord".

Hello, pour moi PDO ne s'amuse pas à remélanger les données de son coté, pour le plaisir. Au pire tu peux lui faire faire du distinct ou group by, mais dans tous les cas ce sera parce que ton script l'a demandé. Bref, vérifie déjà tes 2 requêtes ainsi que tes traitements du résultat en question.

ça se passe donc dans le fichier quickcache_main.php, à la ligne 266 tu as ce pavé : // Not modified! if(stristr($_SERVER["SERVER_SOFTWARE"], "microsoft")) { // IIS has already sent a HTTP/1.1 200 by this stage for // some strange reason header("Status: 304 Not Modified"); } else { if ( $QUICKCACHE_ISCGI ) { header('Status: 304 Not Modified'); } else { header('HTTP/1.0 304'); } } Il suffit donc d'ajouter juste après (ou juste avant) : ini_set('zlib.output_compression', false); Et je t'invite vivement à faire un rapport de bug sur le site de QuickCache afin que d'autres ne rencontrent plus ce problème.

Kaspersky, ce qui confirmerait donc le cas auquel je pensais : un "bug" de PHP connu de longue date qui n'affecte que les scripts gérant le cache HTTP correctement. Il me semblait pourtant que QuickCache avait corrigé ça de son coté. La solution serait donc d'ajouter dans QuickCache un "ini_set('zlib.output_compression', false);" après chaque entête 304 renvoyé (à placer juste après l'appel à header(), avant l'appel à exit()).

Hello, j'ai bien une idée sur la cause du problème mais il me faudrait plus d'infos : est ce que si tu désactives le KeepAlive dans la configuration d'Apache le problème est toujours présent ?

Bonjour, c'est dans le déclaration de mondomaine.com. chez Gandi que tu peux faire les déclaration "glue records" du sous domaine "dns1". A noter que cela fonctionne par "extension" : ton domaine en .org ne pourra dans tous les cas pas annoncer directement les IP de tes DNS en .com La seule exception à ma connaissance concerne les .com et .net qui sont gérés par les mêmes serveurs.

Je n'ai jamais utilisé spamassassin mais quand je lis "X-Spam-Status: Yes, hits=13.4 required=6.0" j'en déduis qu'il détecte bien ça comme du spam, donc l'email devrait être refusé, catch-all ou pas. Non ?

C'est donc que PHP n'est pas interprété, soit parce que tu ne passes pas par Apache comme l'indique captain_torche, soit parce que les "short tags" ne sont pas actifs et dans ce cas il te suffirait d'utiliser les tags complets <?php include() ?>

Si tu fais un "Afficher source" dans ton navigateur, tu vois ce code PHP, une erreur, quelque chose ?

Ca, ça ne veut rien dire du tout. En "ligne" comme tu dis les arborescences sont probablement différentes, la configuration d'Apache/PHP est probablement différente également, tout comme les versions des logiciels. Il y a même fort à parier que les systèmes d'exploitations soient eux aussi différents, tout comme l'architecture (i386 vs amd64). Bref, affirmation sans fondement. Si PHP s'arrête en cours de route, il y a de très grandes chances pour que ce soit à cause d'une erreur, n'aurais tu pas placé des "@" dans le code pour les masquer ?

Bonjour, Oui, l'affichage des erreurs display_errors = on error_reporting = E_ALL | E_STRICT

Bah justement, au départ je pensais que c'était du virtuel (VDS/VPS) cf mon premier message, mais j'avoue avoir un doute. Quand à l'intérêt du VDS, pour ma part je préfère largement avoir un 25% d'un core2quad "haut de gamme" de bonne facture, que 100% d'un core2duo cheap et sans RAID par exemple.

Ce serait entre les deux : ça peut être parce qu'on est "physiquement" plusieurs dessus, ou bien parce qu'on a pas accès à tout (l'accès "administrateur" n'est pas fourni). Mais c'est vrai que c'est bien trop vague, il faudrait préciser de quoi il s'agit.

tout dépend de ce que sous entend le "semi". Si par semi il faut comprendre 1% de la puissance d'un core2quad, non... Si c'est au contraire 50% d'un core2quad, alors oui pourquoi pas. Reste à trouver un prestataire qui annonce les quotas réels.

Bonjour, avec l'option KVM (pas vKVM hein) tu auras accès à "l'écran" du serveur, par contre c'est payant. Sinon histoire de faire repartir le serveur tu peux utiliser un des kernels "netboot" proposés par OVH.

Hello, pour moi à ce niveau les seules techniques potentiellement efficaces seront via JS, afin d'également vérifier que la page en question est bien visible (frames cachés, popunder, etc). Sinon coté PHP il faut jouer sur d'autres éléments, tels que le fait que l'utilisateur télécharge la page en question ainsi qu'une image spécifique sur la page d'accueil.

Et bien ma réticence te souhaite bon courage dans ton entreprise. Sans installer un logiciel dédié à cela (ne serait ce qu'une applet Java) sur le poste de l'internaute, c'est impossible.

Bah ça n'a aucun rapport, tu inverses la "sécurité" là. Un serveur web ne peut pas accéder au poste de l'internaute, encore heureux !

Peu importe, l'accès en question peut être provoqué par n'importe qui, n'importe quoi. Il suffirait que je mette par exemple une redirection/rewriting sur mon avatar pour faire exécuter n'importe quoi aux membres de ce forum...

Un site web qui cherche à accéder aux données personnelles d'un internaute, ça ne te choque vraiment pas ?