J'utilise lighttpd pour servir des fichiers statiques. J'ai un tas d'images dans un répertoire que je mets à jour régulièrement. Cela changera le contenu du fichier (et sa taille) ainsi que la date de modification, mais pas leur nom de fichier.
Lorsque j'accède aux fichiers via http, les mises à jour ne sont pas prises en compte et servent légèrement l'ancien fichier. Je peux renommer manuellement le fichier en quelque chose de différent, puis lighttpd renverra une erreur 404, et si je renomme mon fichier, j'obtiendrai la bonne version mise à jour. On dirait que lightty utilise une sorte de mécanisme de cache qui lui est propre (ce qui est bien) pour renvoyer des fichiers statiques. Malheureusement, il semble que ce mécanisme ne se mette pas à jour lorsque les fichiers sont modifiés.
J'ai vérifié via Wireshark, et mon navigateur fait vraiment une demande au fichier, ce n'est pas un problème de mise en cache du navigateur. Il renvoie un 200 OK lors de la demande à partir d'un cache vide, et un 304 non modifié sinon, comme prévu. Mais le fichier est renvoyé avec un en-tête Last-Modified incorrect qui ne reflète pas la date de dernière modification réelle.
Peut-être y a-t-il une directive de configuration que je ne connais pas?
Je voudrais que les fichiers retournés par lighty reflètent directement les modifications apportées sur le disque, ou au moins puissent invalider son cache.
Mise à jour pour quiconque suit cette question: j'ai trouvé un coupable. Si je mets à jour un fichier statique, Lighty ne renvoie pas le nouveau contenu, mais renvoie le nouveau Content-Length dans ses en-têtes, ce qui entraîne l'affichage des ordures. Si je compresse le fichier à l'aide de mod_compress, le problème disparaît car mod_compress utilise son propre système de mise en cache. Malheureusement, je ne peux pas compresser tous les fichiers (fichiers image par exemple). Ce n'est donc qu'un correctif partiel, mais j'y reviendrai plus tard et je trouverai une solution houleuse.