Thank you for the clarification.
If the map example you gave me should cover when upstream modules are
being used, I don't think my patch will be required anymore.
Regards
On 13/11/2018 19:11, Maxim Dounin wrote:
Hello!
On Fri, Nov 09, 2018 at 08:00:59AM +0000, Thomas Peterson wrote:
Thanks for your response, I didn't consider using a configuration
variable. However upon investigating my patch in greater detail, I have
noticed a difference in behaviour. Consider the following configuration:
proxy_cache_key $scheme$proxy_host$request_uri;
set $var_cache_key $scheme$proxy_host$request_uri;
add_header Proxy-Cache-Key $proxy_cache_key;
add_header Var-Cache-Key $var_cache_key;
I am expecting both of these headers to contain the same value - however
in running this in the nginx test harness does not show this, it shows
the $proxy_host value being empty when interpolated into $var_cache_key.
Attached is the test which should fail against my patch.
I'd appreciate it if you could tell me where I am going wrong.
The problem is that the $proxy_host variable is only available when
proxy starts working. Before this, it is empty, and hence "set",
which is executed during rewrite phase, will use an empty value.
Sorry for the broken example.
If you want to use the $proxy_host variable, the solution would be
to use map instead (http://nginx.org/r/map). That is, something
like this:
map $scheme $cache_key {
default $scheme$proxy_host$request_uri;
}
proxy_cache_key $cache_key;
add_header X-Cache-Key $cache_key;
The map is evaluated (and cached) once proxy_cache_key is
resolved, so there will be no problem like the one with set.
_______________________________________________
nginx-devel mailing list
[email protected]
http://mailman.nginx.org/mailman/listinfo/nginx-devel
