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