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 fran...@daoine.org
_______________________________________________
nginx mailing list -- nginx@nginx.org
To unsubscribe send an email to nginx-le...@nginx.org
