bug of discarding request body
shuxinyang.oss at gmail.com
Mon Nov 23 21:16:27 UTC 2015
Thank you so much for your insightful comment!
Unbuffered-uploading not just to make things easier to reproduce the
It is trivial. So to speak.
It is translating to say it is rather dangerous to use the
with keepalive connections, as the combination make the proxy server
On 11/23/2015 09:53 AM, Maxim Dounin wrote:
> On Mon, Nov 23, 2015 at 09:26:46AM -0800, Shuxin Yang wrote:
>> Hi, Maxim:
>> Thank you very much for the comment, and sorry for my long previous
>> I guess you might misunderstand my previous email. Basically what I try
>> to say
>> is that the *OLD* bug (ticket/669 as you mentioned) is seen on the
>> *PRISTINE* *NEW*
>> 1.9.7 release. The attached script can reproduce the problem by simply
>> The a.sh donwload the 1.9.7 release, build it *without* any 3rd party
>> The problem is triggered by turning off unbuffered-uploading in proxy
>> IIRC, when people report ticket/669, unbuffered-uploading was not available.
> That's an old yet still unfixed bug. Using unbuffered upload is
> just an easy way to trigger it.
>> I guess we ngx_http_discard_request_body() should return NGX_AGAIN
>> instead NGX_OK if discarding body is in progress.
> No, it shouldn't.
>>> Correct fix would be to stop nginx from re-using upstream
>>> connections where a request wasn't completely sent.
>> We cannot tell if it is complete or not if ngx_http_discard_request_body()
>> returns NGX_OK
> We can. In frontend nginx, the one configured with upstream
> keepalive in your test.
> Note well that the problem persists when not nginx but some other
> server is used as a backend. And changing
> ngx_http_discard_request_body() behaviour will be useless.
More information about the nginx