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.

We are using Nginx to serve static files on a development platform. As it is a development platform, we'd like to disable caching so that each change is propagated to the server. The configuration of the VHost is quite simple:

server {
  server_name  static.server.local;
  root /var/www/static;

  ## Default location
  location / {
    access_log        off;
    expires           0;
    add_header        Cache-Control private;
  } 
}

When we access an HTML file (http://static.server.local/test.html), we have no issue: the server returns a code 304 Not Modified as long as the file is not changed, and a 200 OK response with the modified file when the file is changed.
However, it seems to behave differently with a Javascript or a CSS file. Once the file is changed, we get a 200 OK response as expected, but with the old text.
Is there an internal cache mechanism in Nginx that could explain this behaviour? Or some configuration that we should add?

As a side note, here is the header returned by Nginx when the file has been modified (it seems correct):

Accept-Ranges:bytes
Cache-Control:max-age=0
private
Connection:keep-alive
Content-Length:309
Content-Type:text/css
Date:Fri, 13 May 2011 14:13:13 GMT
Expires:Fri, 13 May 2011 14:13:13 GMT
Last-Modified:Fri, 13 May 2011 14:13:05 GMT
Server:nginx/0.8.54

Edit
After trying different settings with the expires directive and Cache-Controlheader, I made some further investigations. In fact, the server is installed on a VirtualBox guest Ubuntu, and data are read from a shared folder that is on the Mac OSX host.
If the file is edited from an IDE (NetBeans) on the host, it seems that changes do not appear whereas if I edit it directly on the guest (using VIM), it is refreshed.
The strange thing is it does not behave similarly with HTML files.
Quite puzzling.

Edit 2 (ANSWER)
Indeed, the origin of the issue was more on the VirtualBox side. Or rather a conflict between VirtualBox and the "sendfile" option of the server.
This link VirtualBox Hates Sendfile gave me the solution: switch the sendfile flag in the server configuration to off:

sendfile  off;

Hope this could also help other person using VirtualBox for development. :)
There are some additional information on the VirtualBox forum.

share|improve this question
3  
Are you running nginx in a vagrant vm and using shared fs? There have been several reports of your symptoms using that combination in #nginx. –  kolbyjack May 13 '11 at 15:46
2  
I could literally hug you!! Have spent 48 hours cursing and going completely mad with this exact issue.., recompiled nginx a few times, sacrificed some small fluffy creatures to assorted deities, learnt the cache directives backwards...all to find out it's one a line oddity to fix thanks to VirtualBox being weird! –  James Butler Dec 11 '11 at 17:10
5  
It would be a lot more clearer if you would post your answer as answer and accept it so everyone can see that this problem was solved. –  Zombaya Jun 20 '12 at 22:37
    
This helped me a lot. Thank you. –  Matt M. Nov 28 '12 at 6:30
    
I got hit by this bug this morning. Wouldn't have realised it was down to the shared folder without this. Thanks! –  Jaffa The Cake Dec 18 '12 at 8:50
show 2 more comments

2 Answers

set your expires tag to

expires off;

and it should not set any expires headers at all, it could also be your browser caching files incorrectly

share|improve this answer
    
Unfortunately, I have tried this as well as expires -1 and the behavior is still the same. –  Olivier Chappe May 13 '11 at 15:06
    
Concerning the browser, I have thought of this possibilities: I was first trying with Chrome, and after modifying a file opened it for the first time in Firefox: I still got the first version of the file. –  Olivier Chappe May 13 '11 at 15:08
    
also the cache-control header should probably be CACHE-CONTROL:NO-CACHE –  anthonysomerset May 13 '11 at 15:11
    
or remove the cache control header altogether - sorry couldnt edit previous comment –  anthonysomerset May 13 '11 at 15:17
    
Thanks for those ideas, I've tried different combinations and then investigated for other possible sources: it seems that Nginx might not be the culprit here. See my edit. –  Olivier Chappe May 13 '11 at 15:54
add comment

This is late, but still marked unanswered, so I will take a stab. Just for giggles, have you tried:

location ~* \.(css|js)$ {
    expires 0;
    break;
}

Haven't tried this myself, but have learned to try this kind of thing with Nginx in a server container from time to time when I have issues similar to this...

share|improve this answer
add comment

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.