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.
_______________________________________________
nginx mailing list
[email protected]
http://mailman.nginx.org/mailman/listinfo/nginx
