[PATCH] Proxy: Adding proxy_cache_key emedded variable

[Maxim Dounin]

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.

-- 
Maxim Dounin
http://mdounin.ru/