Hey!

I found an issue in conjuntion with fastcgi_cache_revalidate. My setup is a bit more complex, so I need to expand a bit, but I think the problem is universal.

I use a php script that generates user profile images according to some url parameters (userid, size, crop settings). As this is a bit slow, I use fastcgi_cache to store the results for a day or so by setting X-Accel-Expires. I also add a string as an Etag-Header and a Cache-Control: public, max-age=86400. The Etag string is a random md5 that is stored in the user database and is updated only when an image is uploaded, deleted or updated. It is also a part of the link and acts as a cache-break.


When I use fastcgi_cache_revalidate on, nginx revalidates the image by requesting the script again after X-Accel-Expires seconds (as desired). When the ETag / If-None-Match header matches the random value in the database, the script sends a 304 Response instead of a newly created copy of the image file. The first problem was that the nginx is doing this for each subsequent request from then on.

In other words on the first day the first request of course is a cache miss and all following requests are cache hits. But after expiration, every following request is a revalidation request, not only the first.

I could overcome this problem by also adding updated Cache-Control/X-Accel-Expires-Headers to the 304-Response in the php script. With this I have one revalidation each day after day 1 and cache hits for the rest of the day.



Problem is that I now have a very similar problem between the browser and nginx. For the first day, the browser uses a memory/disk copy of the image but from day 2 on it tries to fetch the photo from the server again not only once but for every following request. Although those requests result in cache hits or even a 304 / Not modified and are not that costly this requests should not be done at all.


The reason that this occurs is that nginx does not update the (fastcgi_-)cached items with new Date and Cache-Control-Headers when the file was revalidated (that were sent by the script in the 304 Response). It does not matter at this point if nginx actually serves the file from fastcgi_cache or just sends a 304 response, the Expires-/Date-Header that is sent to the client in the past already (or are not sent at all). And I think this actually is a bug.


I tested this with version 1.24.0-1 but I didn't find any change log entries dealing with fastcgi_cache things in the newer version.


I hope I was able to explain the problem clearly, but feel free to ask if anything is unclear.


Kind regards and thanks in advance.
redeye86