[PATCH] Proxy: Adding proxy_cache_key emedded variable

[Thomas Peterson]

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.
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: proxy_cache_key_variable.t
Type: application/x-troff
Size: 2783 bytes
Desc: not available
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20181109/f989f652/attachment.t>