bug of discarding request body

[Shuxin Yang]

Hi, Maxim:

    Thank you so much for your insightful comment!

    Unbuffered-uploading not just to make things easier to reproduce the 
problem.
It is trivial. So to speak.

    It is translating to say it is rather dangerous to use the 
unbuffered-uploading along
with keepalive connections, as the combination make the proxy server 
paper thin
to penetrate.

Thanks
Shuxin

On 11/23/2015 09:53 AM, Maxim Dounin wrote:
> Hello!
>
> 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
>> email.
>>
>>      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
>> invoke
>> "./a.sh"
>>
>>     The a.sh donwload the 1.9.7 release, build it *without* any 3rd party
>> module.
>>
>>     The problem is triggered by turning off unbuffered-uploading in proxy
>> server.
>> 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()
>> always
>> 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.
>