Nginx map value not matched when used as input of another map

[Linna.Ding]

Hi there,

I am having an issue with Nginx map that seems to not match values when the
output variable is the input of another map.

*Case 1: cachestatus_user_agent map is defined separately, not used as
input of wordpress_key map*
*Case 2: cachestatus_user_agent is used as input of wordpress_key map*

Here's my logformat I use to see the results of our maps:
*nginx_logformat.conf*
log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                               '$status $body_bytes_sent "$host"
"$http_referer" '
                               '"$http_user_agent" "$http_x_forwarded_for" '
                               '"$upstream_cache_status" "$request_length" '
                               '"$request_time" "$upstream_response_time" '
                               '"$pipe" "$bytes_sent" "$http_pragma" '
                               '"$http_cache_control" "{external_ip}"
"{instance_name}" '
                               '"$scheme"  "$upstream_status"
"cachestatus_map:$cachestatus_user_agent"
'
                               '"wordpress_key_map:$wordpress_key"';

And then I configure some maps like so:
*nginx.conf*
   http {

       limit_req_zone $wordpress_key zone=wordpress_host:1m rate=1r/m;

* # Here's my initial map*

       map $upstream_cache_status $cachestatus_user_agent {

          HIT $http_user_agent;

          EXPIRED $http_user_agent;

          - $http_user_agent;

          default "";

       }

      *# Successful case, because it starts with a non-mapped var*

map $http_user_agent $wordpress_key {

      *# Failure case, because it starts with a mapped var*

map $cachestatus_user_agent $wordpress_key {

         ~(WordPress) $host;

         default "";

       }



We can see the results below; in the successful case, we see both
cachestatus_map and wordpress_key_map have the expected values:

*Access.log:*
127.0.0.1 - - [13/Jul/2016:16:21:49 -0400] "HEAD / HTTP/1.1" 200 0 "
www.linna-test.com" "-" "WordPress/2.1.1" "-" "HIT" "87" "0.000" "-" "."
"293" "-" "-" "{external_ip}" "{instance_name}" "http"  "-"
"cachestatus_map:WordPress/2.1.1" "wordpress_key_map:www.linna-test.com"

In the failure case, neither value matches. This is especially weird,
because the first map didn't even change between the two cases.

*Access.log:*

127.0.0.1 - - [13/Jul/2016:16:27:32 -0400] "HEAD / HTTP/1.1" 200 0 "
www.linna-test.com" "-" "WordPress/2.1.1" "-" "HIT" "87" "0.000" "-" "."
"293" "-" "-" "{external_ip}" "{instance_name}" "http"  "-" "cachestatus_map:"
"wordpress_key_map:"


What's weird is that I have another limit_req_zone defined with the same
pattern: two maps linked together, and it works. The limit_req_zone and
maps are defined as below. Both $post_remote_addr and
$post_limited_binary_remote_addr
were printed out when I log them.
     limit_req_zone $post_limited_binary_remote_addr zone=post_ip:1m
rate=1r/m;
     map $request_method $post_remote_addr {
         POST $remote_addr;
         default "";
     }
     map $post_remote_addr $post_limited_binary_remote_addr {
        "" "";
        default $binary_remote_addr;
     }

It seems only $upstream_cache_status has this issue, and I searched around
a bit and couldn't find any public issues related to this. Does anyone have
any thoughts on this?

Thanks!
~Linna
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20160714/e93f94a6/attachment.html>