Don't delete timer of write event when it's delayed.

Jiuzhou Cui jiuzhoucui at 163.com
Thu Dec 28 03:03:36 UTC 2023




>You modify r->limit_rate and r->limit_rate_after from your module 

>after sending some parts of the response? 


Yes. This isn't a bug but a requirement, so we need handle it.

OK, I got your idea and no more questions. Thanks.








At 2023-12-27 21:58:48, "Maxim Dounin" <mdounin at mdounin.ru> wrote:
>Hello!
>
>On Wed, Dec 27, 2023 at 08:38:15PM +0800, Jiuzhou Cui wrote:
>
>> Thank you for your reply.
>> 
>> Firstly, we meet the problem. And this patch works for me.
>> 
>> My scenario is after send response body about 10-20MB, we just set:
>> 1. limit_rate = 1KB
>> 2. limit_rate_after = body_bytes_sent
>> 3. proxy_buffering = "on" (I think this is the key issue)
>> 
>> At the request begining, we didn't set proxy_buffering = "on" and limit_rate.
>
>Sorry, not sure what you are trying to say.
>
>You modify r->limit_rate and r->limit_rate_after from your module 
>after sending some parts of the response?  This is not expected to 
>work due to the mentioned design limitation of non-buffered 
>proxying, and generally looks like a bug in your module, it 
>shouldn't do this.
>
>Further, it is not possible to change upstream buffering after 
>nginx started sending the response.  It's a one-time choice, and 
>modifications of r->upstream->buffering won't do anything (though 
>also incorrect, as it's not something expected to be modified by 
>modules).
>
>Or I understood something incorrectly?
>
>-- 
>Maxim Dounin
>http://mdounin.ru/
>_______________________________________________
>nginx-devel mailing list
>nginx-devel at nginx.org
>https://mailman.nginx.org/mailman/listinfo/nginx-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20231228/0b4c0a45/attachment-0001.htm>


More information about the nginx-devel mailing list