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.


Regards


On 07/11/2018 15:45, Maxim Dounin wrote:
> Hello!
>
> On Wed, Nov 07, 2018 at 07:04:38AM +0000, Thomas Peterson wrote:
>
>> To answer your first point around the proxy_cache_key directive,
>> this is to cover for the scenario where a requesting client (or
>> further upstream client) does not have access to the server's
>> proxy_cache_key directive and in a response wants to confirm
>> what actual key was used, not just what the configuration
>> declares. For my own particular deployment this is not a header
>> I would expose to the public, but between tiers in my load
>> balancer hierarchy and when troubleshooting cache performance.
> The point is that there shouldn't much difference between using
> something like
>
> proxy_cache_key $scheme$proxy_host$uri$is_args$args;
> add_header X-Cache-Key $proxy_cache_key;
>
> and using
>
> proxy_cache_key $scheme$proxy_host$uri$is_args$args;
> add_header X-Cache-Key $scheme$proxy_host$uri$is_args$args;
>
> instead - that is, using the same value directly. Or you may
> even do something like
>
> set $cache_key $scheme$proxy_host$uri$is_args$args;
> proxy_cache_key $cache_key;
> add_header X-Cache-Key $cache_key;
>
> so they key used will be guaranteed to match one in the variable,
> also providing an easy access.
>
> While "wants to confirm what actual key was used, not just what
> the configuration declares" might be the reason, it looks more
> like a development and/or debugging task.
>
> Could you please clarify why the above methods does not work in
> your case, and how often the actual key used was different from
> one declared in the configuration in your practice?
>
>> As for renaming the variable, I'm more than happy to do so if
>> you feel that's more appropriate. I chose its current name as
>> the change is part of the proxy codebase, not of upstream.
> The point is that this shouldn't be in the proxy codebase.
>
_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel