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.

Attachment: proxy_cache_key_variable.t
Description: Troff document

_______________________________________________
nginx-devel mailing list
[email protected]
http://mailman.nginx.org/mailman/listinfo/nginx-devel

Reply via email to