Can somebody confirm that proxy_cache_purge is working with
nginx/0.8.34.
I have this config and cannot get it to delete anything from the cache,
I just get a 404:
location / {
proxy_pass http://127.0.0.1:8000;
proxy_cache tmpcache;
proxy_cache_key “$scheme://$host$request_uri”;
}
location ~ /purge(/.*) {
allow 127.0.0.1;
deny all;
proxy_cache_purge tmpcache “$scheme://$host$1”;
}
Thank you.
Posted at Nginx Forum:
Can somebody confirm that proxy_cache_purge is working with nginx/0.8.34.
I just tested it and it works just fine.
Can you confirm that URL that you’re trying to purge is indeed cached?
Can you post access logs (preferably with $upstream_cache_status) for
the
cached URL and for failed purges?
Best regards,
Piotr S. < [email protected] >
My “purge” URL for the home-page (http://www.mysite.com/) is
http://www.mysite.com/purge/
I get a 404 and nothing gets purged.
Same thing if I do it for a URL of this form:
http://www.mysite.com/test-2/2220
http://www.mysite.com/purge/test-2/2220 won’t do anything, just getting
a 404.
GET /test-2/2220 upstream_cache_status HIT
GET /purge/test-2/2220 upstream_cache_status -
Posted at Nginx Forum:
It seems that I keep getting upstream_cache_status UPDATING
Does that mean the purging is scheduled somehow?
Posted at Nginx Forum:
Piotr - is there any way to get proxy_cache_purge to log its activity? I
am not sure it is even working, although I do not get any error message
when restarting NGINX.
Posted at Nginx Forum:
Hi,
location ~ /purge(/.*) {
allow 127.0.0.1;
deny all;
proxy_cache_purge tmpcache “$scheme://$host$1”;
}
http://www.mysite.com/test-2/2220
http://www.mysite.com/purge/test-2/2220 won’t do anything, just getting a
404.GET /test-2/2220 upstream_cache_status HIT
GET /purge/test-2/2220 upstream_cache_status -
Just to make sure: are you requesting purges from localhost (127.0.0.1)?
Piotr - is there any way to get proxy_cache_purge to log its activity? I
am not sure it is even working, although I do not get any error message
when restarting NGINX.
At this time it only logs successful purges at http debug level and
failures
to delete files from hard disk at critical level.
It seems that I keep getting upstream_cache_status UPDATING
Does that mean the purging is scheduled somehow?
No, this has nothing to do with ngx_cache_purge.
Best regards,
Piotr S. < [email protected] >
Hi,
No, why would I, nginx is listening to external IP.
Why would you? Did you at least look at your configuration?
allow 127.0.0.1;
deny all;
Your request is refused before it even reaches ngx_cache_purge module.
how do I see this log? it will give me a clue into what the
proxy_cache_purge is doing
http://wiki.nginx.org/NginxCoreModule#error_log
Best regards,
Piotr S. < [email protected] >
Here’s the config:
location ~ ^/purge(/.*)$ {
allow 127.0.0.1;
allow 192.168.0.0/16;
allow 72.12.74.93;
deny all;
proxy_cache_purge staticfilecache
“$scheme://$host$1”;
}
Posted at Nginx Forum:
Public URL is http://www.mysite.com/test-2/2220
To request purge I try (on local server): wget
www.mysite.com/purge/test-2/2220
or directly from browser (from one of the IPs in allow):
www.mysite.com/purge/test-2/2220
log_format combinedx '$remote_addr - $remote_user [$time_local] ’
'“$request” $status $body_bytes_sent ’
'“$http_referer” “$http_user_agent” ’
'upstream_response_time $upstream_response_time ’
'msec $msec request_time $request_time ’
'Expires: $upstream_http_expires ’
'Cache-Control: $upstream_http_cache_control ’
'upstream_cache_status $upstream_cache_status ';
access_log “/var/log/nginx/access.log” combinedx;
Thank you.
Posted at Nginx Forum:
What IP address are you using to request purge?
Please show entries from properly formatted access log.
Best regards,
Piotr S. < [email protected] >
Just to make sure: are you requesting purges from
localhost (127.0.0.1)?
No, why would I, nginx is listening to external IP.
At this time it only logs successful purges at
http debug level and failures
to delete files from hard disk at critical level.
how do I see this log? it will give me a clue into what the
proxy_cache_purge is doing
It seems that I keep getting
upstream_cache_status UPDATING
Does that mean the purging is scheduled somehow?No, this has nothing to do with ngx_cache_purge.
correct.
Thank you.
Posted at Nginx Forum:
74.65.58.194 - - [15/Mar/2010:00:35:29 -0400] “GET /purge/ HTTP/1.0” 404
^^^^^^^^^^^^
this IP isn’t on your allowed list:
allow 127.0.0.1;
allow 192.168.0.0/16;
allow 72.12.74.93;
Question: what am I supposed to see/get after a successful purge?
http://blog.s135.com/attachment/201001/nginx_purge.png
Thanks for all your help Piotr but I don’t want to waste your time
indefinitely.
All I need is to see the activity log for proxy_cache_purge, and we can go
from there.
All you need to do is use proper access list. There is no activity when
your
request is blocked in the access phase.
Best regards,
Piotr S. < [email protected] >
74.65.58.194 - - [15/Mar/2010:00:35:29 -0400] “GET /purge/ HTTP/1.0”
404 1656 “-” “Wget/1.11.4 Red Hat modified” upstream_response_time -
msec 1268627729.628 request_time 0.000 Expires: - Cache-Control: -
upstream_cache_status -
Question: what am I supposed to see/get after a successful purge?
Thanks for all your help Piotr but I don’t want to waste your time
indefinitely.
All I need is to see the activity log for proxy_cache_purge, and we can
go from there.
Thank you.
Posted at Nginx Forum:
That is a dummy IP.
I cannot investigate your problem when you’re giving me false data.
I believe that, if cache file doesn’t exist response is still 404.
Yes, it is.
Wouldn’t be helpful to return a message “cache file does not exists”
instead of a 404.
No, 404 is standard HTTP response code for “File Not Found” and it is
exactly the response that any sane person would expect when “cached
file”
does not exist. There is no way that this is gonna change.
Best regards,
Piotr S. < [email protected] >
That is a dummy IP.
Now, seeing is believing – I gave it another try and it actually gave
me the response similar to the screenshot.
Not sure why but it is very sporadic. I believe that, if cache file
doesn’t exist response is still 404.
Of course, the cache file exists, therefore question is - why so
sporadic.
Wouldn’t be helpful to return a message “cache file does not exists”
instead of a 404.
Thanks again.
Posted at Nginx Forum:
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs