<div dir="ltr">Thanks!</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jan 12, 2023 at 1:36 PM J Carter <<a href="mailto:jordanc.carter@outlook.com">jordanc.carter@outlook.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">It's trivial to do with error page OP as mentioned - an example:<br>
<br>
limit_req_status 598;<br>
limit_req_zone $binary_remote_addr zone=a:1m rate=1r/m;<br>
<br>
server {<br>
limit_req zone=a nodelay;<br>
<br>
error_page 598 = @send-204;<br>
<br>
location / {<br>
...<br>
}<br>
<br>
...<br>
<br>
location @send-204 {<br>
return 204;<br>
}<br>
}<br>
<br>
error_page's '=' can also be set to 204, and the named location contain <br>
nothing at all (whatever you prefer).<br>
<br>
On 12/01/2023 17:11, Maxim Dounin wrote:<br>
> Hello!<br>
><br>
> On Thu, Jan 12, 2023 at 05:16:21AM -0800, Christopher Liebman wrote:<br>
><br>
>> Not with 204.<br>
>> This works quite well with a partner that has an aversion to errors when<br>
>> they run over the limit:<br>
>> limit_req_status 204;<br>
> Indeed, 204 happens to be one of the two 2xx codes which can be<br>
> returned directly, as they are handled in<br>
> ngx_http_finalize_request() to facilitate simpler<br>
> code in the dav module. This is not what your patch enables<br>
> though. For all other codes, except 204 and 201 mentioned above,<br>
> just returning them will simply break things.<br>
><br>
> As already suggested, proper behaviour for all the codes can be<br>
> easily configured by using the "error_page" directive.<br>
><br>
> Hope this helps.<br>
><br>
_______________________________________________<br>
nginx-devel mailing list<br>
<a href="mailto:nginx-devel@nginx.org" target="_blank">nginx-devel@nginx.org</a><br>
<a href="https://mailman.nginx.org/mailman/listinfo/nginx-devel" rel="noreferrer" target="_blank">https://mailman.nginx.org/mailman/listinfo/nginx-devel</a><br>
</blockquote></div>