Thank you for the clarification.

If the map example you gave me should cover when upstream modules are
being used, I don't think my patch will be required anymore.

Regards

On 13/11/2018 19:11, Maxim Dounin wrote:
> Hello!
>
> On Fri, Nov 09, 2018 at 08:00:59AM +0000, Thomas Peterson wrote:
>
>> 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.
> The problem is that the $proxy_host variable is only available when
> proxy starts working. Before this, it is empty, and hence "set",
> which is executed during rewrite phase, will use an empty value.
> Sorry for the broken example.
>
> If you want to use the $proxy_host variable, the solution would be
> to use map instead (http://nginx.org/r/map). That is, something
> like this:
>
> map $scheme $cache_key {
> default $scheme$proxy_host$request_uri;
> }
>
> proxy_cache_key $cache_key;
> add_header X-Cache-Key $cache_key;
>
> The map is evaluated (and cached) once proxy_cache_key is
> resolved, so there will be no problem like the one with set.
>
_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel