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-leave@nginx.org