How can I combine this into 1 block? - nginx

Question

I am trying to set the $qualifies variable to 1 if both the path = "/" AND the query variable "band" != "". I've been able to figure out the separate sections below (I think) but wanted to know if there is an easier way. Seems like this could all be in 1 map:
map $request_uri $myvar {
~(?<captured_path>[^?]*) $captured_path;
}
map $arg_band $band{
"" 0;
default 1;
}
map "$myvar:$band" $qualifies{
default 0;
"/:1" 1;
}
Want to do it 'cause ugly and know there's probably a better way.

Answer 1

It seems like weren't aware that a query-less URL is already available within $uri, so, another potential solution is as follows:
map $uri:$arg_band $qualified {
default 0;
~^/:[^:]+$ 1;
}
Note both $uri and $arg_band can contain "weird" characters (e.g., both can contain ?, in case of $uri, through %3f), so, you gotta be sure in your regex to match your actual separator, and not a placeholder supplied by the user. This can either be done by making it random, long and secret, or by restricting the acceptable input from the user.
Note that without knowing what other logic is employed and how it makes use of the variables, most of the obvious and good-looking solutions would actually contain potential security vulnerabilities and be incorrect (e.g., the solution above may be incorrect if $arg_band does contain :).

Answer 2

Abstract
So, you're trying to set $qualifies to 1 if both $uri is / and $arg_band is not set to anything?
Basic Idea
The basic idea compared to your own code is that we have to do an inverse of the logical and operation to a logical or — (a && b) is always the same as !(!a || !b) — and once you know the theory, then the rest is simply a bit of coding.
And, indeed, it's very simple to do with a single http://nginx.org/r/map:
map $request_uri $qualifies {
default 1;
~^[^?]+[?]band=[^&] 0; # match if $arg_band set to .+, case 1
~^[^?]+[?].*&band=[^&] 0; # match if $arg_band set to .+, case 2
~^[/]+[^/?]+ 0; # match if $uri is set to "/"
}
Discussion
If you don't like the double cases for handling $arg_band, you can use the lookbehind operator of pcre, however, I believe that the above two cases might actually be more efficient and correct than the single one below:
^[^?]+[?].*(?<=[?&])band=[^&] # incorrect! will match /??band=a
A follow-up question I personally had was whether the above combined regex is actually correct, and would match the way nginx does its own parsing for $arg_band. This can be tested by running various strings against an nginx.conf that simply does something like return 200 $args\t$arg_band\t$uri\t$request_uri\n;; what I found out is that $uri is always cut at the first ?, whereas $args itself may contain the second ?, whereas the individual variable names must either start from the first ? of the request, or from & anytime after the first question mark, e.g., a question mark within $args is treated as a regular character, so, the above lookbehind code w/ (?<=[?&]) is incorrect due to the different matching of a string like /??band=t between the regex and actual $arg_band in nginx.
So, if you still want to combine the two expressions, then perhaps the following should be the most correct one:
^[^?]+[?](?:.*&)?band=[^&]
Summary
Making the overall solution:
map $request_uri $qualifies {
default 1;
~^[^?]+[?](.*&)?band=[^&] 0;
~^[/]+[^/?]+ 0;
}
However, you also have to consider how absolutely correct your solution has to be, and if a very high degree of correctness is required, then it may not be appropriate to do your own parsing of $request_uri (just as an example, when $request_uri is /a/../, the $uri will be just / due to URL normalisation, and your original solution already suffered from this).