nginx proxy_pass and proxy_cache
Francis Daly
francis at daoine.org
Thu Nov 11 08:54:21 UTC 2021
On Wed, Nov 10, 2021 at 08:58:54PM +0200, Reinis Rozitis wrote:
Hi there,
> > And I can't make a location block for a mimetype, or using another specifier than regexes to filter out requests to certain 'file types'. Is there any other 'good' solution except for, on my origin adding rewrites from /something/data1/ to /data1/?
Assuming that other proxy criteria are the same, I think that the "map"
suggestion with a variable for proxy_cache will be the simplest.
But if you have reasons to want more explicit config:
> Why just not separate the locations rather make them nested?
>
> Something like:
>
> location /something/ {
> proxy_cache disk_cache;
> proxy_pass http://origin/data1/;
> }
>
> location ~* ^/something/.*\.xml$ {
> proxy_cache fast_disk_cache;
> proxy_pass http://origin/data1/;
> }
I think that that one would fail for the same reason as the initial
attempt: proxy_pass-with-URI and regex location do not go well together.
http://nginx.org/r/proxy_pass :
"""
In some cases, the part of a request URI to be replaced cannot be determined:
"""
lists three cases, and this is case#1.
As it happens, you *can* do it if you take advantage of case#3.
location ~* ^/something/(.*\.xml)$ {
proxy_cache fast_disk_cache;
proxy_pass http://origin/data1/$1;
}
(although you probably want to capture to a named variable, instead of
hoping that $1 has not changed by the time proxy_pass uses it -- see
http://nginx.org/en/docs/http/server_names.html#regex_names and choose
the syntax that your version uses. Probably (?<this_bit>.*\.xml), and
then use $this_bit.)
You could possibly also take advantage of case#2, and do
rewrite /something/(.*\.xml)$ /$1 break;
but that feels a bit too subtle to me.
Note that the regex-matching attempts may not do what you want if you
have %-encodings in the incoming requests -- test your use cases to see
that things work for you.
Or just use the map.
Good luck with it,
f
--
Francis Daly francis at daoine.org
More information about the nginx
mailing list