location regex?

[Francis Daly]

On Wed, Aug 03, 2022 at 08:39:32PM -0400, Jay Haines wrote:

Hi there,

> I am trying to weed out requests for any uri that contains the string,
> "announce" (no quotes). That would include
> 
>  * /announce
>  * /announce/
>  * /announce.php

Normal config there would be of the form

	location ~ announce {}

but only in a place where that location will actually have a chance to
be matched -- so before any other ~regex location that might match the
same request; and any =exact location, or ^~prefix location that is
the longest-prefix match, will mean that regex matches are not tried.

> each with or without query strings. I have the following location blocks in
> my server context:
> 
>        location ~* announce {
>                return 444;
>        }
> 
>        location ~* /announce.php {
>                return 444;
>        }

In that sequence, that second one will never be used.

But that's ok; it has the same handling as the first one.

> and my log looks good:
> 
> "122.100.172.162"       "03/Aug/2022:20:19:00 -0400"    "GET /announce.php?info_hash=%DF%AEF%40%7F%1DA%C9%91S%9F%D4%0D%D6J%E6%992%A3~&peer_id=-BC0171-_sSI%D1n%AA%A9%C3%A5%25%1E&port=15302&natmapped=1&localip=172.18.80.247&port_type=lan&uploaded=46317568&downloaded=11285925264&left=178446055&numwant=50&compact=1&no_peer_id=1&key=38892
> HTTP/1.1"        "444"   "0"     "0.000"  "-"     "BitComet/1.71.9.7"
> 
> until it doesn't:
> 
> "81.110.165.170"        "03/Aug/2022:20:24:03 -0400"    "GET /announce.php?info_hash=%5B%EA0r%8A*8%C4%DAA%81%02%B4%BF%97%CC%1E%A9y%C8&am_peer_id=-TR300%5A-LDXTt3fAIyq%00&port=43342&uploaded=0&downloaded=0&left=5593535899&event=started&key=0&compact=1&numwant=200
> HTTP/1.1" "400"   "150"   "0.000" "-"     "-"

If those two requests went to the same server{}, and there was no
other config that will have handled them differently, they would both be
handled in the same location{} (because each request was "/announce.php",
as far as location matching is concerned).

The second response is 400, which is "Bad Request", which can come
from nginx before any location{} matching is attempted. For example --
something claiming to be a HTTP/1.1 request but not having a Host:
header can lead to a log line like that.

> I have tried various location prefixes and regexes (and combinations
> thereof) but can't seem to find the one that works correctly.

The first location{} that you have looks correct to me, in normal
nginx terms.

If you can investigate the 400-request, maybe you can see whether
the response came from nginx directly, or came from something later
that involved the announce.php code. (With the config shown, I expect
it will have been a "real" bad request, so was rejected before the
location-matching (and probably also the server-matching) happened.)

Cheers,

	f
-- 
Francis Daly        francis at daoine.org