7

I can't seem to find enough documentation. I have an app that generates some dynamic responses, but could still benefit from the Last-Modified header -- so I send it.

However, turning on if_modified_since (set to before, per http://nginx.org/en/docs/http/ngx_http_core_module.html#if_modified_since) doesn't seem to have any effect on non-static resources. E.g., php, python apps.

Is this because Nginx isn't just looking at my response Last-Modified header? Because I can see that they appear to be set correctly, as below:

> GET /3.0/view.json?id=2 HTTP/1.1
> Host: xxxxxxxxxxxxx
> Accept: */*
> If-Modified-Since: Sat, 02 May 2015 19:43:02 GMT
>
< HTTP/1.1 200 OK
* Server nginx/1.4.7 is not blacklisted
< Server: nginx/1.4.7
< Date: Fri, 01 May 2015 19:56:05 GMT
< Content-Type: application/json; charset=utf-8
< Transfer-Encoding: chunked
< Connection: keep-alive
< Vary: Accept-Encoding
< Last-Modified: Fri, 01 May 2015 19:56:05 GMT

Or is there something larger that I'm overlooking? Just curious how if_modified_since is implemented, compared to where I'm setting my expectations. I assumed it would just look at the response headers, and over-ride the status as necessary. Am I wrong?

1
  • Does nginx consider a query with arguments cachable by default? I know this is a point of difference in various caching products, but I'm not familiar enough with nginx to know for that. May 2, 2015 at 9:57

2 Answers 2

5

Sending Last-Modified headers in your app replies is a start but it seems you don't handle If-Modified-Since properly on incoming requests because your app should reply 304 Not Modified and not 200 OK. Changing the directive on nginx only impact requests served directly by nginx i.e. static ressources unless you configure it as a reverse proxy cache. In this case, you may serve stale replies regarding this header value since content will be cached for a period of time without hitting your app. Turning <X>_cache_revalidate on will use the If-Modified-Since header to revalidate cache content between nginx's cache and your app once it has expired (where <X> = proxy / fastcgi / scgi / uwsgi)

1
  • Thanks. This line clears up my underlying question: Changing the directive on nginx only impact requests served directly by nginx i.e. static ressources unless you configure it as a reverse proxy cache. -- E.g., Nginx does not act on non-static content, without extra configuration. THANKS! May 3, 2015 at 16:50
0

Since you have not mentioned anything about your cache configuration in Nginx, I'm going to assume you did not set a cache, and this would explain why your If-Modified-Since header has no effect for dynamic responses.

When it comes to static resources, Nginx has a really easy way to determine how to handle If-Modified-Since: it compares the time in the field with the time the file was last modified. No problem there.

When you want Nginx to do the same with dynamically generated responses, there's nothing for it to compare against, unless you turn on caching. By default, Nginx does not remember the responses it has served. When you turn caching on, Nginx has a way to compare an incoming request with a response previously given, and thus has a way to use If-Modified-Since.

I've found this article really useful to learn the finer details of setting an Nginx cache.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .