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.

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.

Regards


On 06/11/2018, 19:15, "nginx-devel on behalf of Maxim Dounin" <nginx-devel-bounces@nginx.org on behalf of mdounin@mdounin.ru> wrote:

Hello!

On Sat, Nov 03, 2018 at 09:00:02AM +0000, Thomas Peterson wrote:

> # HG changeset patch
> # User Thomas Peterson <hidinginthebbc@gmail.com>
> # Date 1541231609 0
> # Sat Nov 03 07:53:29 2018 +0000
> # Node ID 41a499230eb674b1b3ec7cfd093f3a074f9a0d09
> # Parent bddacdaaec9ef174504899f1528155f84bf60e59
> Proxy: Adding proxy_cache_key emedded variable
>
> This value being able to be set as part of response headers allows for greater
> debugging of caching, and to permit analytics on cache-key distribution.

What's the expected difference with using the same value as in the
proxy_cache_key directive?

Also, shouldn't this be $upstream_cache_key instead, to ensure
that a single variable can be used for all protocol-specific
modules?

[...]

--
Maxim Dounin
http://mdounin.ru/
_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel



_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel