<div dir="ltr"><div class="gmail_default" style="color:#444444">I am developing an AuthZ module. <br><br>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):</div><div class="gmail_default" style="color:#444444"><br></div><div class="gmail_default" style="color:#444444">curl -s -I <a href="http://localhost/login?{1..3}">http://localhost/login?{1..3}</a><br>HTTP/1.1 200 OK<br>Server: nginx/1.21.6<br>Date: Sun, 04 Dec 2022 16:43:17 GMT<br>Content-Type: text/html; charset=utf-8<br>Content-Length: 1651<br>Connection: keep-alive<br><br>HTTP/1.1 429 Too Many Requests<br>Server: nginx/1.21.6<br>Date: Sun, 04 Dec 2022 16:43:17 GMT<br>Content-Type: text/html<br>Content-Length: 169<br>Connection: keep-alive<br><br>HTTP/1.1 429 Too Many Requests<br>Server: nginx/1.21.6<br>Date: Sun, 04 Dec 2022 16:43:17 GMT<br>Content-Type: text/html<br>Content-Length: 169<br>Connection: keep-alive<br></div><div class="gmail_default" style="color:#444444"><br></div><div class="gmail_default" style="color:#444444"><br></div><div class="gmail_default" style="color:#444444">However, doing the same for POST requests, this does not work:<br><br></div><div class="gmail_default" style="color:#444444">curl -s -w "\nStatus: %{http_code}\n\n" <a href="http://localhost/login?{1..3}">http://localhost/login?{1..3}</a> --data-raw 'username=user&password=user'<br>login success: user<br>Status: 200<br><br>login success: user<br>Status: 200<br><br>login success: user<br>Status: 200<br></div><div class="gmail_default" style="color:#444444"><br></div><div class="gmail_default" style="color:#444444">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). <br></div><div class="gmail_default" style="color:#444444"><br></div><div class="gmail_default" style="color:#444444">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.</div><div class="gmail_default" style="color:#444444"><br></div><div class="gmail_default" style="color:#444444">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.</div><div class="gmail_default" style="color:#444444"><br></div><div class="gmail_default" style="color:#444444">Thanks</div><div class="gmail_default" style="color:#444444">Jeremy</div><div class="gmail_default" style="color:#444444"><br></div><div class="gmail_default" style="color:#444444"><br></div><div class="gmail_default" style="color:#444444"><br></div><div class="gmail_default" style="color:#444444"><br></div><div class="gmail_default" style="color:#444444"><br></div><div class="gmail_default" style="color:#444444"><br></div><div class="gmail_default" style="color:#444444"><br></div><div class="gmail_default" style="color:#444444"><br></div><div class="gmail_default" style="color:#444444"><br></div><div class="gmail_default" style="color:#444444"><br></div></div>