Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I am using lighttpd to serve static files. I have a bunch of images in a dir that I regularly update. This will change the file content (and filesize) as well as the modification date, but not their filename.

When I access the files through http, the updates are not taken into account and lighty serves the old file. I can manually rename the file to something different, then lighttpd will return a 404 error, and if I rename my file back, I will get the correct updated version. Seems like lightty is using some kind of cache mechanism of its own (which is fine) to return static files. Unfortunatly, it seems that this mechanism doesn't update itself when files are modified.

I checked through Wireshark, and my browser is really doing a request to the file, this is not a browser caching issue. It returns a 200 OK when requesting it from an empty cache, and a 304 Not Modified otherwise, as expected. But the file is returned with a wrong Last-Modified header that do not reflect the real last modification date.

Maybe there is some config directive that I am not aware of ?

I would like the files returned by lighty to reflect the changes made on disk directly, or at least being able to invalidate its cache.

Update for anyone following this question : I found a culprit. If I update a static file, Lighty does not return the new content, but does return the new Content-Length in its headers, resulting in garbage displayed. If I compress the file using mod_compress, the issue goes away as mod_compress uses its own caching system. Unfortunatly, I can't compress all the files (image files for example). So it is only a partial fix, but I'll get back to it later and will hoepfully find a solution.

share|improve this question

5 Answers 5

up vote 6 down vote accepted

I've finally found the issue. And it comes from VirtualBox.

When editing a file in the Host (Win), lighttpd in the guest (Linux) does not correctly update the file content (but does correctly update file size), thus returning cropped or garbled content.

Unmounting my shared drives and re-mounting them, or editing files directly in the guest, fixed the issue.

It took me 6 months to finally figure that out.

share|improve this answer

You don't mention whether you have mod_cache installed or not? This module defaults to 'enabled' when installed.

I'm loathe to suggest it, but does turning on Etags help?

share|improve this answer
    
mod_cache isn't installed. ETags are enabled (but inode is not used to generate the ETag). I tried enabling inode, or disabling ETag, but to no avail. –  Pixelastic Jun 23 '11 at 8:13

Try setting stat engine caching to 'disabled':

server.stat-cache-engine = "disable'
share|improve this answer
    
Thanks, but this has no effect. However, I didn't know that directive, and it might come in handy later. –  Pixelastic Jun 21 '11 at 15:19
    
There might be a middle man proxy between you and the server? Try restarting your server and accessing the same file. Are you using mod_compress? –  Aleksey Korzun Jun 21 '11 at 15:24
    
I'm running a Ubuntu VM in a Windows 7 host. Lighty is in the VM. I don't think there might be a proxy issue here. I've restarted the server, but this does not clear lighty cache. I'm using mod_compress but not on those files. I'll try restarting the whole VM and disabling mod_compress to see if it changes anything. Thanks for the ideas. –  Pixelastic Jun 21 '11 at 16:30
    
Hmm, I might have something here. If I change the file to a smaller one (but keeping the same name), I got only the top half of my file. Seems like the old file is displayed with the content-length of the current one. If I replace with a bigger file, the whole (old) file is displayed. Seems like the filesize changes are taken into account but not the file content. –  Pixelastic Jun 21 '11 at 16:38
    
Sorry for spamming comments : disabling mod_compress does not change anything, nor does restarting the whole VM. –  Pixelastic Jun 21 '11 at 16:42

This lighttpd option worked for me

server.network-backend = "writev" 
share|improve this answer
    
Worked like a charm for me, on a Debian VM on a Debian desktop, thanks! –  Yvan Jan 24 at 20:35

Try these etag entries and see if they help you any:

Cache control rules for lighthttpd

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.