如何将其组合成1个块?

时间:2017-12-15 04:07:28

标签: nginx

如果路径=" /"我试图将$ qualifies变量设置为1和查询变量" band" !=""。我已经能够找出下面的各个部分(我想),但想知道是否有更简单的方法。似乎这可能都在1张地图中:

map $request_uri $myvar {
    ~(?<captured_path>[^?]*) $captured_path;
}

map $arg_band $band{
  "" 0;
  default 1;
}

map "$myvar:$band" $qualifies{
  default 0;
  "/:1" 1;
}

想要这样做会导致丑陋并且知道可能是更好的方式。

2 个答案:

答案 0 :(得分:1)

摘要

所以,如果$qualifies 1 $uri/未设置为任何内容,您是否尝试将$arg_band设置为(a && b)

基本理念

与您自己的代码相比,我们必须将逻辑 操作的反转与逻辑 - !(!a || !b)始终与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 "/" } 相同 - 一旦您了解了理论,那么剩下的就是编码。

事实上,使用单个http://nginx.org/r/map非常简单:

$arg_band

讨论

如果您不喜欢处理 ^[^?]+[?].*(?<=[?&])band=[^&] # incorrect! will match /??band=a 的双重案例,您可以使用pcre的lookbehind运算符,但是,我相信上述两种情况实际上可能比下面的单曲:

$arg_band

我个人的一个后续问题是上面的组合正则表达式是否真的正确,并且与nginx自己解析return 200 $args\t$arg_band\t$uri\t$request_uri\n;的方式相匹配。这可以通过针对nginx.conf运行各种字符串来测试,这些字符串只执行类似$uri的操作;我发现?总是在第一个$args被剪切,而?本身可能包含第二个?,而单个变量名必须从请求的第一个&,或第一个问号后的任何时间$args,例如,(?<=[?&])中的问号被视为常规字符,因此,上面的后观代码w / /??band=t不正确,因为正则表达式与nginx中的实际$ arg_band之间的^[^?]+[?](?:.*&)?band=[^&] 字符串匹配不同。

所以,如果你仍然希望将两个表达式结合起来,那么以下应该是最正确的表达式:

map $request_uri $qualifies {
    default 1;
    ~^[^?]+[?](.*&)?band=[^&] 0;
    ~^[/]+[^/?]+ 0;
}

摘要

制定整体解决方案:

$request_uri

但是,您还必须考虑解决方案必须绝对正确,如果需要非常高的正确性,则可能不适合自己解析$request_uri(就像例如,当/a/../$uri时,由于网址规范化,/将只是class Demo{ public static void main (String args[]){ String x = "PN:VYZ,CPU:45,MEM:24,IO:93,CPU:39,MEM:2,IO:83,CPU:17,MEM:-2,IO:65,CPU:41,MEM:9"; String []arr = x.split(","); System.out.println(arr[0]); System.out.println(arr[1]); } } ,并且您的原始解决方案已经受此影响了。“

答案 1 :(得分:1)

似乎没有意识到$uri中已经有了无需查询的网址,因此,另一个可能的解决方案如下:

map $uri:$arg_band $qualified {
    default 0;
    ~^/:[^:]+$ 1;
}

请注意,$uri$arg_band都可以包含&#34;奇怪的&#34;字符(例如,两者都可以包含?in case of $uri, through %3f),因此,您必须确保在正则表达式中匹配您的实际分隔符,而不是用户提供的占位符。这可以通过使其随机,冗长和保密,或通过限制用户可接受的输入来完成。

请注意,在不知道使用了什么其他逻辑以及如何使用变量的情况下,大多数明显且美观的解决方案实际上都会包含潜在的安全漏洞并且不正确(例如,如果{上述解决方案可能不正确} {1}}包含$arg_band)。