Disable open_file_cache for a specific location

Server NGINX
1

I have set the open_file_cache variable to max=5000 inactive=20s so
that it
is enabled globally but now I want to disable all caching for a specific
virtual location on a domain:

  • open_file_cache max=5000 inactive=20s;
    – location ^~ /gallery {
    open_file_cache off;
    }

Sadly that rule doesn’t work because /gallery doesn’t exist as a real
folder. It is only a permalink (/%category%/%postname%/) from WordPress.
All
subpages (like www.domain.tld/gallery/flickr) should have no cache
enabled
because the plugin for those galleries doesn’t work with caching.
How can I solve the problem?
Thanks in advance.

Posted at Nginx Forum:

2

On Tue, Jul 02, 2013 at 05:24:15PM -0400, Peleke wrote:

Hi there,

I have set the open_file_cache variable to max=5000 inactive=20s so that it
is enabled globally but now I want to disable all caching for a specific
virtual location on a domain:

Module ngx_http_core_module describes what open_file_cache does.

That description doesn’t seem to match what you seem to indicate you
think it does.

  • open_file_cache max=5000 inactive=20s;
    – location ^~ /gallery {
    open_file_cache off;
    }

Sadly that rule doesn’t work because /gallery doesn’t exist as a real
folder.

Why do you think that it doesn’t work?

What test do you do; what result do you see; and what result do you
expect to see?

It is only a permalink (/%category%/%postname%/) from WordPress. All
subpages (like www.domain.tld/gallery/flickr) should have no cache enabled
because the plugin for those galleries doesn’t work with caching.

nginx tends not to cache unless you configure it to.

Why do you think nginx is caching something that you do not want it to?

How can I solve the problem?

I suspect that describing the problem in terms of specific things that
can be observed or tested will be a good start.

Right now, I’m not sure what problem you are reporting.

f

Francis D. [email protected]

3

Sorry, maybe it is only related to the permalink structure which worked
with
Apache before server move.
The gallery script adds it own extensions to the address.
You can see it live on www.peleke.de/galerie and then click on one of
the
three gallery sources (Flickr, Facebook or Google+).
Can you see what I mean?

Posted at Nginx Forum:

4

On Tue, Jul 02, 2013 at 08:16:00PM -0400, Peleke wrote:

Hi there,

Sorry, maybe it is only related to the permalink structure which worked with
Apache before server move.

Could be; the fact that this is a new nginx deployment which used to be
an apache deployment is probably useful information for when it comes
to fixing the nginx configuration.

The gallery script adds it own extensions to the address.
You can see it live on www.peleke.de/galerie and then click on one of the
three gallery sources (Flickr, Facebook or Google+).
Can you see what I mean?

No.

I don’t see anything there which is obviously cache-related.

I do see the words “Gallery not found!!!”.

So: when you type a specific curl command – such as “curl -i
http://www.peleke.de/galerie/facebook/” – what response do you get and
what response do you expect?

And what nginx configuration do you use that leads you to get and expect
those things?

f

Francis D. [email protected]

5

On Wed, Jul 03, 2013 at 09:45:44AM -0400, Peleke wrote:

Try Flickr or Google+ instead, that error message isn’t related to the
problem I mentioned, sorry.

Good news! I see no evidence of the nginx-related problem that you have
described, on either of those two pages, so I presume that you fixed it
before I looked.

f

Francis D. [email protected]

6

Try Flickr or Google+ instead, that error message isn’t related to the
problem I mentioned, sorry.

Posted at Nginx Forum:

7

On 3 July 2013 23:17, Francis D. [email protected] wrote:

On Wed, Jul 03, 2013 at 09:45:44AM -0400, Peleke wrote:

Try Flickr or Google+ instead, that error message isn’t related to the
problem I mentioned, sorry.

Good news! I see no evidence of the nginx-related problem that you have
described, on either of those two pages, so I presume that you fixed it
before I looked.

+1.

I also checked Yahoo and LinkedIn just to be sure. No problems there,
either.

J

8

No, the problem is not solved: You can see the album thumbnails but when
you
click on them there should be a page with the different pictures from
that
album which you can view in full screen mode.
You can see how it should work on http://wp.oopstouch.com/?page_id=22
and I
think the problem is related to the URL and permalink structure.

Posted at Nginx Forum:

9

Sorry but my last message was delayed, may be you didn’t see it but the
problem is still not solved and it worked before with Apache. I would be
happy if you could help me, thanks!

Posted at Nginx Forum:

10

The problem still exists. You can only see the album thumbnails but it
should be possible to click on them to see all pictures from an album
and
then see them in full screen.

Posted at Nginx Forum:

11

On Sun, Jul 07, 2013 at 04:27:23PM -0400, Peleke wrote:

Hi there,

Sorry but my last message was delayed, may be you didn’t see it but the
problem is still not solved and it worked before with Apache. I would be
happy if you could help me, thanks!

From all of the words you have written so far, I still do not know of
any one url which you access which gives you a response that is
different
in a specific way from what you expect to get.

If you choose not to provide information, I fail to be surprised if
others aren’t inspired to try to help you.

My suggestion is that you do whatever it takes to write a short
nginx.conf
which can be used to demonstrate the failure that you are trying to
report.

(Probably: begin with your current nginx.conf, and remove lines which
are not immediately obviously necessary, testing after each removal to
confirm that things that did work do still work, and that the thing that
did fail does still fail.)

If it turns out that you can’t reproduce the failure, then
congratulations, you have fixed it.

Otherwise, send the the no-more-than-50-line nginx.conf that is
sufficient
for anyone else to use to build their own failing test system.

And include the output of “nginx -V”, and include a very clear and
specific:

  • I access this url.
  • I expect to see this output.
  • I actually see this output.

and, if it is not immediately obvious:

  • the difference between the last two is this.

Good luck with it,

f

Francis D. [email protected]

12

Okay:

This is the demo gallery of the gallery plugin I (want to) use:
http://wp.oopstouch.com/?page_id=22

As you can see the first thumbnail pictures are thumbnails for different
albums. When you click on one of them the album will be opened and then
you
can click on a thumbnail picture again to open it in fullscreen.

If you compare that with my gallery (which worked before with Apache)
here:
http://www.peleke.de/galerie/google/
Nothing happens after a click on an album thumbnail. You will only see a
reload of the page and this added to the URL:
?page_id=0&albid=5898003541337462625 (for example) which should show the
thumbnail pictures of the album.

Maybe it is just a simple URL problem (that was solved in a .htaccess
file
with Apache before) or expires js problem!?
I am no expert and would be happy if you could help me, thanks!

Different nginx conf files:

sendfile        on;
tcp_nopush     on;
tcp_nodelay on;

types_hash_max_size 2048;

send_timeout 2;

client_max_body_size 20m;
client_body_buffer_size 128k;
client_body_timeout 10;
client_header_timeout 10;
keepalive_timeout 10;

open_file_cache          max=5000  inactive=20s;
open_file_cache_valid    30s;
open_file_cache_min_uses 2;
open_file_cache_errors   on;

gzip  on;
gzip_http_version 1.1;
gzip_vary on;
gzip_comp_level 6;
gzip_proxied any;
gzip_types text/plain text/css application/json

application/x-javascript
text/xml application/xml application/xml+rss text/javascript
application/javascript text/x-js;
gzip_buffers 16 8k;
gzip_disable “MSIE [1-6].(?!.*SV1)”

location ~* ^.+.(jpg|jpeg|gif|css|js|png|ico|html|xml|txt)$ {
access_log off;
expires modified max;
}

location ~ /.ht {
deny all;
}

fastcgi_split_path_info ^(.+.php)(/.+)$;

location / {
    try_files $uri $uri/ /index.php;
    #include /etc/nginx/proxy_params;
}

location ~ \.php$ {
    #limit_req zone=limit burst=5 nodelay;
    try_files $uri =404;
    #fastcgi_pass unix:/var/run/php5-fpm.sock;
    fastcgi_pass 127.0.0.1:9000;
    fastcgi_index index.php;
    fastcgi_intercept_errors off;
    fastcgi_read_timeout 120;
    fastcgi_buffers 256 4k;
    fastcgi_param SCRIPT_FILENAME

$document_root$fastcgi_script_name;
include /etc/nginx/fastcgi_params;
}

Posted at Nginx Forum:

13

On Mon, Jul 08, 2013 at 03:42:31PM -0400, Peleke wrote:

Hi there,

http://www.peleke.de/galerie/google/
Nothing happens after a click on an album thumbnail. You will only see a
reload of the page and this added to the URL:
?page_id=0&albid=5898003541337462625 (for example) which should show the
thumbnail pictures of the album.

I think that you are saying:

http://www.peleke.de/galerie/google/ does return the expected content,
and
http://www.peleke.de/galerie/google/?page_id=0&albid=5898003541337462625
does not return the expected content; instead it returns the same
content as http://www.peleke.de/galerie/google/, as if the part after
the ? is being ignored.

Correct?

location / {
    try_files $uri $uri/ /index.php;
    #include /etc/nginx/proxy_params;
}

If you use your favourite web search engine and look for the
equivalent of “site:wordpress.org nginx”, you’ll probably get to
http://codex.wordpress.org/Nginx

If you search for “site:nginx.org wordpress”, you’ll probably get to
http://wiki.nginx.org/WordPress

They both have a “location /” block which is not the same as yours.

The difference does seem to relate to the part after the ?.

Do things work any better if you use what they suggest?

f

Francis D. [email protected]

14

On Tue, Jul 09, 2013 at 09:11:56AM -0400, Peleke wrote:

Hi there,

Yes, you are right. Such a small change!

Yes. nginx and wordpress do tend to work well together, so “typical”
fixes are usually straightforward.

Thanks a lot and sorry for taking such a long time. Next time I know how to
post a proper question.

You’re welcome; no worries. The more specific a problem report is,
the more chance any mailing list has of finding the answer.

All the best,

f

Francis D. [email protected]

15

Yes, you are right. Such a small change!
Thanks a lot and sorry for taking such a long time. Next time I know how
to
post a proper question.

Posted at Nginx Forum: