s-maxage not being honored with proxy_cache

Ryan Parrish ryan.parrish at corelogicllc.com
Wed Apr 24 13:51:20 UTC 2013

On Wed, Apr 24, 2013 at 7:41 AM, Maxim Dounin <mdounin at mdounin.ru> wrote:

> Hello!
> On Tue, Apr 23, 2013 at 11:05:58AM -0400, Ryan Parrish wrote:
> > I have a slow backend application that I'm using nginx to provide
> > the authentication and caching for.  It's been working great however
> there
> > is one nagging issue that I cannot seem to resolve, when the backend app
> > sets a s-maxage and a maxage Cache-Control, nginx only seems to honor the
> > maxage and expires the cache with its value.
> >
> > An example response from the backend is like this...
> >
> > Cache-Control: max-age=60, s-maxage=3600, public, must-revalidate
> > My idea here is I only want the client to cache this data for a short
> > amount of time before checking in with me it see if it's still valid.
>  The
> > data usually wont be changing that often so I want nginx to cache it for
> an
> > hour, but in the event it does I use the excellent nginx-cache-purge
> script
> > in my backend app to invalidate the cache and the next time a client
> checks
> > in (after 60 seconds) they will get the new data.
> Note: you will not be able to purge shared chaches outside of your
> control, so this might not work as you expect.
> > However in all my testing and usage I will only get a cache HIT for 60
> > seconds after the first request to a resource, after 60 seconds it will
> be
> > EXPIRED then it will go to the backend again.  Am I missing something in
> > the Cache-Control that is causing this behavior?
> As of now nginx doesn't handle s-maxage.
> Trivial solution is to use X-Accel-Expires to specifi expiration
> time for your nginx cache.  This should also better match a use
> case you've described (as it will only ask your nginx cache to
> cache longer, not all shared caches in the world).
That worked perfectly, thank you!



Ryan Parrish
Chief Technologist, Member
CoreLogic LLC
M: (408)966-4673

solutions for the extended enterprise
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20130424/a0de28af/attachment.html>

More information about the nginx mailing list