Bonjour, Malgré pas mal d'essais et de recherches, je n'arrive pas à outrepasser mon problème. Je m'explique :
J'ai configuré un nginx en reverse proxy devant un apache. Basique me direz-vous. Dommage de ne faire que ça, du coup, je rajoute du cache et pour tester, je mets une validité de mon cache très faible : proxy_cache_valid 10s;
Donc normalement, si je change un fichier test.png à la racine du site, au bout de 10 secondes, il devrait me servir la nouvelle version non ?
J'ai probablement loupé quelque chose sur le fonctionnement de ce truc mais je ne trouve pas d'autre paramètre en rapport avec cette fonction.
Une idée ?
Merci d'avance, Julien
Le 2014-09-22 17:06, Julien Escario a écrit :
Bonjour, Malgré pas mal d'essais et de recherches, je n'arrive pas à outrepasser mon problème. Je m'explique :
J'ai configuré un nginx en reverse proxy devant un apache. Basique me direz-vous. Dommage de ne faire que ça, du coup, je rajoute du cache et pour tester, je mets une validité de mon cache très faible : proxy_cache_valid 10s;
Donc normalement, si je change un fichier test.png à la racine du site, au bout de 10 secondes, il devrait me servir la nouvelle version non ?
J'ai probablement loupé quelque chose sur le fonctionnement de ce truc mais je ne trouve pas d'autre paramètre en rapport avec cette fonction.
Une idée ?
Merci d'avance, Julien _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
deux idées comme une autre qui peuvent avoir un impact : - Le cache de ton navigateur - Le cache de ton proxy
Cdlt,
JYL
Le 22 septembre 2014 17:06, Julien Escario escario@azylog.net a écrit :
Donc normalement, si je change un fichier test.png à la racine du site, au bout de 10 secondes, il devrait me servir la nouvelle version non ?
Ton fichier est servi par une application ou c'est du direct ? Si tu passes par un CMS ou consort, il peut t'ajouter des tags différents de ceux de ton serveur web.
Autre cas, sous apache / mod_expires, il y a 2 gestions de caches possible : un cache par accès et un cache par date de modification du fichier. En fonction de ta politique, le comportement n'est pas le même.
Nicolas
Le 22/09/2014 17:53, Nicolas Steinmetz a écrit :
Le 22 septembre 2014 17:06, Julien Escario <escario@azylog.net mailto:escario@azylog.net> a écrit :
Donc normalement, si je change un fichier test.png à la racine du site, au bout de 10 secondes, il devrait me servir la nouvelle version non ?Ton fichier est servi par une application ou c'est du direct ? Si tu passes par un CMS ou consort, il peut t'ajouter des tags différents de ceux de ton serveur web.
J'ai essayé de faire le plus direct possible : c'est un fichier png posé directement à la racine, normalement hors de tout contrôle du CMS.
Autre cas, sous apache / mod_expires, il y a 2 gestions de caches possible : un cache par accès et un cache par date de modification du fichier. En fonction de ta politique, le comportement n'est pas le même.
Et si c'était ça justement ? Est-ce que nginx honorerait les en-têtes de mod_expires ? Genre : "mon cache pour ce fichier est expiré, je refais une requête à Apache. Ah mais non : Apache m'a dit qu'il était valable pendant une semaine donc je reprends le même."
Possible ?
Julien
Salut,
Nginx peut prendre en compte les entêtes posées par Apache, mais normalement proxy_cache_valid les surchargent, pour les ignorer complètement, voir proxy_ignore_headers : http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_ignore_header...
________________________________________ De : FRsAG [frsag-bounces@frsag.org] de la part de Julien Escario [escario@azylog.net] Date d'envoi : lundi 22 septembre 2014 18:03 Cc: French SysAdmin Group Objet : Re: [FRsAG] Nginx et expiration du cache
Le 22/09/2014 17:53, Nicolas Steinmetz a écrit :
Le 22 septembre 2014 17:06, Julien Escario <escario@azylog.net mailto:escario@azylog.net> a écrit :
Donc normalement, si je change un fichier test.png à la racine du site, au bout de 10 secondes, il devrait me servir la nouvelle version non ?Ton fichier est servi par une application ou c'est du direct ? Si tu passes par un CMS ou consort, il peut t'ajouter des tags différents de ceux de ton serveur web.
J'ai essayé de faire le plus direct possible : c'est un fichier png posé directement à la racine, normalement hors de tout contrôle du CMS.
Autre cas, sous apache / mod_expires, il y a 2 gestions de caches possible : un cache par accès et un cache par date de modification du fichier. En fonction de ta politique, le comportement n'est pas le même.
Et si c'était ça justement ? Est-ce que nginx honorerait les en-têtes de mod_expires ? Genre : "mon cache pour ce fichier est expiré, je refais une requête à Apache. Ah mais non : Apache m'a dit qu'il était valable pendant une semaine donc je reprends le même."
Possible ?
Julien
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
un "curl -I <url>" sur l'url nginx et sur celle proxyfiée pourrait nous aider au debug.
Le 22 septembre 2014 18:12, HURTEVENT VINCENT < vincent.hurtevent@univ-lyon1.fr> a écrit :
Salut,
Nginx peut prendre en compte les entêtes posées par Apache, mais normalement proxy_cache_valid les surchargent, pour les ignorer complètement, voir proxy_ignore_headers : http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_ignore_header...
De : FRsAG [frsag-bounces@frsag.org] de la part de Julien Escario [ escario@azylog.net] Date d'envoi : lundi 22 septembre 2014 18:03 Cc: French SysAdmin Group Objet : Re: [FRsAG] Nginx et expiration du cache
Le 22/09/2014 17:53, Nicolas Steinmetz a écrit :
Le 22 septembre 2014 17:06, Julien Escario <escario@azylog.net mailto:escario@azylog.net> a écrit :
Donc normalement, si je change un fichier test.png à la racine dusite, au
bout de 10 secondes, il devrait me servir la nouvelle version non ?Ton fichier est servi par une application ou c'est du direct ? Si tu
passes par
un CMS ou consort, il peut t'ajouter des tags différents de ceux de ton
serveur web.
J'ai essayé de faire le plus direct possible : c'est un fichier png posé directement à la racine, normalement hors de tout contrôle du CMS.
Autre cas, sous apache / mod_expires, il y a 2 gestions de caches
possible : un
cache par accès et un cache par date de modification du fichier. En
fonction de
ta politique, le comportement n'est pas le même.
Et si c'était ça justement ? Est-ce que nginx honorerait les en-têtes de mod_expires ? Genre : "mon cache pour ce fichier est expiré, je refais une requête à Apache. Ah mais non : Apache m'a dit qu'il était valable pendant une semaine donc je reprends le même."
Possible ?
Julien
Liste de diffusion du FRsAG http://www.frsag.org/ _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Bonjour, Merci de vos différentes réponses.
Je continue mes investigations et par acquis de conscience, j'ai rajouté :
proxy_ignore_headers Set-Cookie Cache-Control Expires X-Accel-Expires;
(oui, j'ai fait dans le lourd sans trop réfléchir, ce comportement commence à me gaver)
Dans la config de mon vhost nginx. A priori, ça ne change rien. Plusieurs heures après, j'ai toujours mon image de 2881 octets qui est servie : $ curl -I "http://www.voixdumidilauragais.fr/test.png" HTTP/1.1 200 OK Server: nginx/1.6.0 Date: Tue, 23 Sep 2014 07:43:14 GMT Content-Type: image/png Content-Length: 2881 Connection: keep-alive Last-Modified: Mon, 22 Sep 2014 13:43:01 GMT ETag: "72a19d-b41-503a7a11ce340" Cache-Control: max-age=10 Expires: Tue, 23 Sep 2014 07:43:24 GMT Accept-Ranges: bytes
Alors que le fichier fait 3081 octets : # ls -la test.png -rw-r--r-- 1 root root 3081 22 sept. 18:36 test.png
En tapant directement sur Apache, j'ai bien le nouveau fichier : # curl -I "http://www.voixdumidilauragais.fr/test.png" HTTP/1.1 200 OK Date: Tue, 23 Sep 2014 07:45:30 GMT Server: Apache/2.2.22 (Debian) Last-Modified: Mon, 22 Sep 2014 16:36:31 GMT ETag: "72a19d-c09-503aa0d98e1c0" Accept-Ranges: bytes Content-Length: 3081 Cache-Control: max-age=2592000 Expires: Thu, 23 Oct 2014 07:45:30 GMT Content-Type: image/png
Bref, je sèche complètement là ...
Julien
Le 22/09/2014 18:17, Greg a écrit :
un "curl -I <url>" sur l'url nginx et sur celle proxyfiée pourrait nous aider au debug.
Le 22 septembre 2014 18:12, HURTEVENT VINCENT <vincent.hurtevent@univ-lyon1.fr mailto:vincent.hurtevent@univ-lyon1.fr> a écrit :
Salut, Nginx peut prendre en compte les entêtes posées par Apache, mais normalement proxy_cache_valid les surchargent, pour les ignorer complètement, voir proxy_ignore_headers : http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_ignore_headers ________________________________________ De : FRsAG [frsag-bounces@frsag.org <mailto:frsag-bounces@frsag.org>] de la part de Julien Escario [escario@azylog.net <mailto:escario@azylog.net>] Date d'envoi : lundi 22 septembre 2014 18:03 Cc: French SysAdmin Group Objet : Re: [FRsAG] Nginx et expiration du cache Le 22/09/2014 17:53, Nicolas Steinmetz a écrit : > > Le 22 septembre 2014 17:06, Julien Escario <escario@azylog.net <mailto:escario@azylog.net> > <mailto:escario@azylog.net <mailto:escario@azylog.net>>> a écrit : > > Donc normalement, si je change un fichier test.png à la racine du site, au > bout de 10 secondes, il devrait me servir la nouvelle version non ? > > > Ton fichier est servi par une application ou c'est du direct ? Si tu passes par > un CMS ou consort, il peut t'ajouter des tags différents de ceux de ton serveur web. J'ai essayé de faire le plus direct possible : c'est un fichier png posé directement à la racine, normalement hors de tout contrôle du CMS. > Autre cas, sous apache / mod_expires, il y a 2 gestions de caches possible : un > cache par accès et un cache par date de modification du fichier. En fonction de > ta politique, le comportement n'est pas le même. Et si c'était ça justement ? Est-ce que nginx honorerait les en-têtes de mod_expires ? Genre : "mon cache pour ce fichier est expiré, je refais une requête à Apache. Ah mais non : Apache m'a dit qu'il était valable pendant une semaine donc je reprends le même." Possible ? Julien _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/ _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
Bonjour,
Moi aussi j'avais seché un jour pour le même type de problème, j'ai du faire une cache zone avec une key:
http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_cache http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_cache_key
Et si ton backend te r'envois des Set-Cookie dans son header. Désactive les car sinon t'auras pas de cache.
proxy_ignore_headers "Set-Cookie";
Bon courage.
Edouard Buschini On Sep 22, 2014 5:06 PM, "Julien Escario" escario@azylog.net wrote:
Bonjour, Malgré pas mal d'essais et de recherches, je n'arrive pas à outrepasser mon problème. Je m'explique :
J'ai configuré un nginx en reverse proxy devant un apache. Basique me direz-vous. Dommage de ne faire que ça, du coup, je rajoute du cache et pour tester, je mets une validité de mon cache très faible : proxy_cache_valid 10s;
Donc normalement, si je change un fichier test.png à la racine du site, au bout de 10 secondes, il devrait me servir la nouvelle version non ?
J'ai probablement loupé quelque chose sur le fonctionnement de ce truc mais je ne trouve pas d'autre paramètre en rapport avec cette fonction.
Une idée ?
Merci d'avance, Julien _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Le 23/09/2014 10:10, Buschini Edouard a écrit :
Bonjour,
Moi aussi j'avais seché un jour pour le même type de problème, j'ai du faire une cache zone avec une key:
http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_cache http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_cache_key
Alors j'ai déjà ça : proxy_cache_key "$scheme://$host$request_uri";
Pas bon ?
Et si ton backend te r'envois des Set-Cookie dans son header. Désactive les car sinon t'auras pas de cache.
proxy_ignore_headers "Set-Cookie";
Oui, on va y venir en affinant parce que les CMS ont tendance à filer un cookie pour n'importe quelle ressource. On peut aussi définir des domaines 'statiques' pour certaines ressources et sur lesquels on vire explicitement les cookies.
Pour le moment, c'est plutôt l'inverse : j'ai trop de cache.
Julien
Bonjour, Bon he bien j'ai testé, il me semble, toutes les solutions proposées sans succès. Je ne comprends pas ce qui peut bien empêcher ce rafraîchissement de cache ...
Du coup, vous êtes tous sous varnish ?
Julien
Le 23/09/2014 11:09, Julien Escario a écrit :
Le 23/09/2014 10:10, Buschini Edouard a écrit :
Bonjour,
Moi aussi j'avais seché un jour pour le même type de problème, j'ai du faire une cache zone avec une key:
http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_cache http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_cache_key
Alors j'ai déjà ça : proxy_cache_key "$scheme://$host$request_uri";
Pas bon ?
Et si ton backend te r'envois des Set-Cookie dans son header. Désactive les car sinon t'auras pas de cache.
proxy_ignore_headers "Set-Cookie";
Oui, on va y venir en affinant parce que les CMS ont tendance à filer un cookie pour n'importe quelle ressource. On peut aussi définir des domaines 'statiques' pour certaines ressources et sur lesquels on vire explicitement les cookies.
Pour le moment, c'est plutôt l'inverse : j'ai trop de cache.
Julien _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
NGiNX a tendance à un peu trop respecter le protocole HTTP 1.1 et à empêcher de le contourner ... mais on ne va pas lui jeter la pierre !
Je pense qu'il faut plutôt que tu essayes de modifier la config Apache.
Le 25 septembre 2014 18:03, Julien Escario escario@azylog.net a écrit :
Bonjour, Bon he bien j'ai testé, il me semble, toutes les solutions proposées sans succès. Je ne comprends pas ce qui peut bien empêcher ce rafraîchissement de cache ...
Du coup, vous êtes tous sous varnish ?
Julien
Le 23/09/2014 11:09, Julien Escario a écrit :
Le 23/09/2014 10:10, Buschini Edouard a écrit :
Bonjour,
Moi aussi j'avais seché un jour pour le même type de problème, j'ai du faire une cache zone avec une key:
http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_cache http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_cache_key
Alors j'ai déjà ça : proxy_cache_key "$scheme://$host$request_uri";
Pas bon ?
Et si ton backend te r'envois des Set-Cookie dans son header. Désactive
les car sinon t'auras pas de cache.
proxy_ignore_headers "Set-Cookie";
Oui, on va y venir en affinant parce que les CMS ont tendance à filer un cookie pour n'importe quelle ressource. On peut aussi définir des domaines 'statiques' pour certaines ressources et sur lesquels on vire explicitement les cookies.
Pour le moment, c'est plutôt l'inverse : j'ai trop de cache.
Julien _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
Le 25/09/2014 18:03, Julien Escario a écrit :
Bonjour, Bon he bien j'ai testé, il me semble, toutes les solutions proposées sans succès. Je ne comprends pas ce qui peut bien empêcher ce rafraîchissement de cache ...
Du coup, vous êtes tous sous varnish ?
Nginx fait très bien le boulot et lorsqu'il est déjà serveur web il peut cumuler les deux fonctions, pourquoi ajouter Varnish du coup. Varnish sert plus quand les règles de mises en cache sont complexes et différentes en fonction des backends, là oui Varnish gagne à être utilisé.
Il faut effectivement filtrer les annonces du CMS si il envoie un cookie sur des statics ou un des autres headers de gestion de cache. Set-Cookie, Pragma, Cache-Control, Expire, virer le etag Après le mieux c'est aussi de définir des règles pour dire à nginx quoi mettre en cache et quoi bypasser ou mettre avec un cache très léger genre 1h.
Le mieux pour tester c'est un curl -I sur le proxy et un autre sur le serveur web en direct pour comparer et voir ce que tu veux garder et ce que tu veux laisser passer.
Pour les éléments à ne pas mettre en cache ne pas hésiter à forcer à Expire négatif ça permet aussi de contourner les réglages des navigateurs qui n'en ont que faire que tu mettes un expire à 5m par exemple.
-
Buschini Edouard -
Greg -
HURTEVENT VINCENT -
jean-yves＠lenhof.eu.org -
Julien Escario -
Nicolas Steinmetz -
Wallace