I am developing an AuthZ module. While testing using the rate limiting module. I can see rate limiting kick in for GET requests fine (it's tuned extra low to demonstrate this case):
curl -s -I http://localhost/login?{1..3} HTTP/1.1 200 OK Server: nginx/1.21.6 Date: Sun, 04 Dec 2022 16:43:17 GMT Content-Type: text/html; charset=utf-8 Content-Length: 1651 Connection: keep-alive HTTP/1.1 429 Too Many Requests Server: nginx/1.21.6 Date: Sun, 04 Dec 2022 16:43:17 GMT Content-Type: text/html Content-Length: 169 Connection: keep-alive HTTP/1.1 429 Too Many Requests Server: nginx/1.21.6 Date: Sun, 04 Dec 2022 16:43:17 GMT Content-Type: text/html Content-Length: 169 Connection: keep-alive However, doing the same for POST requests, this does not work: curl -s -w "\nStatus: %{http_code}\n\n" http://localhost/login?{1..3} --data-raw 'username=user&password=user' login success: user Status: 200 login success: user Status: 200 login success: user Status: 200 Setting my module to run in the `precontent` phase allows this to work, so it's all happening in rewrite (where the rate limiting module would be kicking in). I obviously don't want to run in precontent and my module gets its advice from an external "agent" as to what to set the status. So I'm assuming it is overwriting the nginx rate limiting module's status and setting it back to a 200, when I'd rather respect the rate limiting modules 429. What would be the best approach here to avoid this from happening? I have read about module ordering, but that would require a recompile of my end, however, I am more intrigued about how to handle this in code. Thanks Jeremy
_______________________________________________ nginx mailing list -- nginx@nginx.org To unsubscribe send an email to nginx-le...@nginx.org
