Problem with proxy cache misses

CJ Ess zxcvbn4038 at gmail.com
Mon Feb 29 21:49:22 UTC 2016


The catch-all entry works and don't conflict with the = /. That solves my
second problem, thank you!


On Mon, Feb 29, 2016 at 3:32 PM, Wandenberg Peixoto <wandenberg at gmail.com>
wrote:

> The location = / is a exactly match.
> To execute a "catch all" returning a 404 you can do a
>
> location / {
>   return 404;
> }
> On Feb 29, 2016 16:15, "Payam Chychi" <pchychi at gmail.com> wrote:
>
>> Look at your proxy cache path... (proxy_cache_path /var/www/test_cache)
>> Are you sure the path exists and had proper perms/ownership?
>>
>> Payam
>>
>>
>> On Feb 29, 2016, 11:03 AM -0800, CJ Ess <zxcvbn4038 at gmail.com>, wrote:
>>
>> Hello! I'm testing out a new configuration and there are two issues with
>> the proxy cacheing feature I'm getting stuck on.
>>
>> 1) Everything is a cache miss, and I'm not sure why:
>>
>> My cache config (anonymized):
>>
>> ...
>> proxy_cache_path /var/www/test_cache levels=2:2 keys_zone=TEST:32m
>> inactive=365d max_size=16g loader_files=256;
>> ...
>>   upstream haproxy {
>>     server 127.0.0.1:8080;
>>     keepalive 256;
>>   }
>> ...
>>     location ~ "^/[W][A-Za-z0-9_-]{7,13}$" {
>>       limit_except GET {
>>         deny  all;
>>       }
>>       proxy_http_version 1.1;
>>       proxy_set_header Connection "Close"; # Disable Keepalives
>>       proxy_set_header Host "www.testhost.com"; # Upstream requires this
>> value
>>       proxy_set_header X-Real-IP $remote_addr;
>>       proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
>>       proxy_set_header X-Forwarded-Proto https;
>>       proxy_cache TEST;
>>       proxy_cache_key $uri;
>>       proxy_cache_valid 301 365d;
>>       proxy_cache_valid 302 1d;
>>       proxy_cache_lock on;
>>       proxy_buffering off;
>>       proxy_pass http://haproxy;
>>     }
>> ...
>>
>> A sample response coming back from the upstream (captured with wireshark)
>>
>> HTTP/1.1 301 Moved Permanently
>> Date: Mon, 29 Feb 2016 18:16:02 GMT
>> Content-Type: text/html
>> Transfer-Encoding: chunked
>> Connection: close
>> P3P: CP="some text"
>> X-Frame-Options: deny
>> Location: http://some.test.url/
>>
>> 0
>>
>> The cache directory is owned by the nginx user, perms 0700.
>>
>> I'm expecting the 301 in the example above to be cached for a year, but
>> nothing is created under /var/www/test_cache, and subsequent requests for
>> the same resources are also cache misses.
>>
>> 2) For each URL which doesn't match any of the location blocks, I am
>> seeing an error in the log file:
>>
>> 2016/02/29 13:55:20 [error] 19524#0: *1509121054 open()
>> "/var/www/html/W4ud7y1k4jjbj" failed (2: No such file or directory),
>> client: a.b.c.d, server:test.com, request: "HEAD /W4ud7y1k4jjbj
>> HTTP/1.1", host: "test.com"
>>
>> There is a "root /var/www/html" defined in the http block, although there
>> is only one specific location which uses it:
>>
>>     location = /apple-app-site-association {
>>       default_type application/pkcs7-mime;
>>       break;
>>     }
>>
>> And the final location block in my server config is:
>>
>>     location = / {
>>       rewrite ^ https://www.someother.test.com/ permanent;
>>       break;
>>     }
>>
>> So my expectation is that since the request matches none of the location
>> blocks, nginx will just issue a 404 response. However from the error log,
>> it looks like it is trying the root directory first before issuing the 404.
>> Is there some way to prevent that?
>>
>>
>>
>>
>>
>> _______________________________________________
>> nginx mailing list
>> nginx at nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx
>>
>>
>> _______________________________________________
>> nginx mailing list
>> nginx at nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx
>>
>
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20160229/ac1d562a/attachment.html>


More information about the nginx mailing list