-
Notifications
You must be signed in to change notification settings - Fork 246
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
'expires epoch' directive causes upstream cache headers to be ignored #198
Comments
I can confirm that removing 'expires epoch' allows the Cache-Control header specified by Drupal to come through correctly. |
After reading the following, having expires epoch here makes sense for revalidating the actual page using ETags:
In your example, I see expires epoch does affect the headers for content type xml for you, but for me it doesn't. XML files are served directly in drupal.conf by following location directive: |
I'm wondering about this myself now... have commented out expires epoch and sure enough my I've just patched cache_warmer to create a microcache on a single thread as per https://www.drupal.org/node/2362927 and despite a 'headers already sent' error I'm getting from that in drush (deleting microcache manually hasn't resolved that particular issue yet), I'm not at all sure if microcache is being used at this point :) Any further advice on this issue welcome. |
Oddly enough, I'm unsure if microcache is working at all. I've tried it both ways, however, I am always seeing an Expired value on the microcache header. |
I managed to get a cache hit to show using Ctrl+F5, refreshing the page approx. 10 times. It's crude, but it got the cache to show itself in the headers. I knew it must have been working as the blitz.io rush tests were showing nearly 700 hits/sec were not causing any errors or timeouts (with keepalive option on), it was just a case of seeing it for myself. Emulating the rush tests on a mini-scale did it. |
@luxpir am I right in saying you've just confirmed microcache is working? Is this with or without the I still believe that the |
@cclafferty Well, I've confirmed I get cache HIT reported in the headers when I hammer the site. This is consistent with how microcaching should work. That's as much as I can say for sure. This is with How's it looking at your end? |
Thanks for this. This confirms that microcache is working which I suspected The cache problems we are now faced with are those sent onward to the
|
I tested a few things because I read in a few places that:
But then I wondered how useful this is, given that in the marek.sapota.org link posted above, it says about the
Isn't that exactly what we want from microcaching? Isn't |
Thanks for this @luxpir. I think the issue here is that we shouldn't be changing Cache-Control headers at all. The problem is still that Drupal is setting them and Nginx is overriding them which is confusing behaviour and shouldn't happen. Even if we were to decide that I first noticed this problem whilst using CloudFlare which will not cache any content that specifies |
@cclafferty the idea of micro caching is to have a small TTL cache so that even if your content changes frequently your site will be able to withstand a great load. If OTOH you want nginx to obey the cache headers you need to comment out the line that sets the expiration to the UNIX Epoch expires epoch; Now if you want to force nginx to obey the upstream ## The Cache-Control and Expires headers should be delivered untouched
## from the upstream to the client.
fastcgi_ignore_headers Cache-Control Expires; |
Hi @perusio, great project. Let me just say this before you close the Now please to close this once and for all observe a Drupal site which I Please check out: You will observe a correct Cache-Control header which Drupal has sent (I On Mon, 19 Oct 2015 at 15:26, António P. P. Almeida <
|
@cclafferty I think you're mixing things a little bit. nginx cannot set the upstream headers. nginx can only set client headers. What in fact happens is that by setting the expiration date to the UNIX Epoch we say to the client that the page has already expired, hence the client has to request it all the time, i.e., for all requests. The idea of microcaching is protecting the backend/upstream. Yes you get another request for a page reload, but it goes to the cache. Only after the microcache validity expires you'll get a fresh page from the upstream. Since the cache manager uses a lock to prevent stampeding you'll get never more than a single upstream request during the time validity of the lock. If comment out the expires epoch line then the upstream caching headers take effect on the client. For the server is different. That's what you're seeing. I suggest you comment also the |
Hi @perusio thanks for your patience on this. I believe we've had a misunderstanding regarding what we'd call upstream. To me I'm talking about the client. You clearly understand what is going on, can you explain why you choose to deliberately expire the cache on the client? Surely the upstream Cache-Control headers from Drupal are more suitable? |
@durist the reason is simplicity. It's easier to reason about the caching in your application if you use only one authority.: the server or the upstream. By setting it to the UNIX Epoch there's no interaction between the client and the server. Yes it makes the client hit the cache on the server, but if you decide to change the TTL or for you the freshness of the content is important, then you know exactly when a client will get an updated version of a page: as soon as the cache expires and a new version is fetched from the upstream. tl;dr - to avoid interactions between client cache and server cache - having a single authority for TTL |
Hi @perusio just wanted to say thanks for clearing this up. Throughout this entire thread we thought this was a bug or at least some unwanted side effect. Although I may not agree with Nginx being the authority on cache at least this was done by design. I would recommend leaving a comment surrounding the tags |
Thanks for providing clarification on this - you have an excellent implementation of Nginx. I just have couple of questions for you.
Thanks for your help in advance. |
apps/drupal/microcache_fcgi.conf has the following:
However, the
expires epoch
line apparently takes precedence overfastcgi_ignore_headers Cache-Control Expires;
Headers with
expires epoch;
:Identical configuration without
expires epoch;
:It looks like the
expires epoch
directive is redundant and should be removed.The text was updated successfully, but these errors were encountered: