Also, It might be better to check the $arg_*argument *variable instead and
also set a check for $is_args. NGINX will process them in order within the
configuration.

map $is_args $redirect {
"?" "1";
default "";
}

map $arg_emailaddress $redirect {
~.+%40[a-zA-Z0-9\.\-] '';
default "1";
}

On Sat, Mar 4, 2017 at 7:06 PM, Kevin Jones <kevin@nginx.com> wrote:

> Hi,
>
> You would be better to accomplish this with map. Would this work?
>
> map $args $redirect {
> ~emailaddress=.+%40[a-zA-Z0-9\.\-] '';
> default "1";
> }
>
> server {
> ...
> location / {
> ...
> }
>
> location /foo {
> if ($redirect) { return 301 /; }
> ...
> }
>
> }
>
> On Sat, Mar 4, 2017 at 1:52 PM, 173279834462 <nginx-forum@forum.nginx.org>
> wrote:
>
>> Hello,
>>
>> Our local policy demands the rejection of any query; we do this as
>> follows:
>> if ($is_args) { return 301 /; }
>>
>> The introduction of Thunderbird autoconfiguration demands an exception to
>> the above policy, because of
>> "GET
>> /.well-known/autoconfig/mail/config-v1.1.xml?emailaddre=uname%
>> 40example.com".
>>
>> The resulting rule would be
>>
>> if (($is_args) && ($args !~ emailaddress=.+%40[a-zA-Z0-9\.\-]+)) { return
>> 301 /; }
>>
>> The rule does not work, because nginx does not parse the AND condition.
>>
>> Of course, you cannot just remove $is_args, because $args is usually
>> empty.
>>
>>
>> The alternative would be if ($args ~ emailaddress=.+%40[a-zA-Z0-9\.\-]+))
>> {
>> allow all; } else { return 301 /; },
>> but nginx does not parse if-then-else statements.
>>
>> Are we stuck in the cage?
>>
>> Posted at Nginx Forum: https://forum.nginx.org/read.p
>> hp?2,272758,272758#msg-272758
>>
>> _______________________________________________
>> nginx mailing list
>> nginx@nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx
>>
>
>


--
Kevin Jones
Technical Solutions Architect | NGINX, Inc.
kevin@nginx.com
Skype/Twitter @webopsx
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx