<div dir="ltr">Well, I appreciate the time every contributor to nginx put into the project and especially your and Igor's work, and I know I don't dictate the priority of your TODO, but I humbly think this is a far more serious issue than you're portraying.<div>
<br></div><div>Simply put, this bug can cause nginx to cause an otherwise *noticeable data corruption* to become a *silent data corruption* (including the serious cache poisoning ramifications), and I think there are few bugs less urgent than that.</div>
<div><br></div><div>Anyhow, I've said all I have to say on the matter, so unless further information comes up on this, I'll leave this topic alone (at least until I'll get off my bum and come back here with a suggested patch to fix this...).</div>
<div><br></div><div>Thank you for your concise, timely and complete reply,</div><div> - Yaniv</div><div><br><div class="gmail_quote">On Fri, Sep 30, 2011 at 12:59 PM, Maxim Dounin <span dir="ltr"><<a href="mailto:mdounin@mdounin.ru">mdounin@mdounin.ru</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hello!<br>
<div class="im"><br>
On Fri, Sep 30, 2011 at 11:11:53AM +0300, Yaniv Aknin wrote:<br>
<br>
> In a recent thread on the uwsgi mailing list[1], I began suspecting that<br>
> nginx will not honor an upstream's Content-Length header. i.e., if an<br>
> upstream mentions a Content-Length of 1,000 bytes, but the connection is<br>
> broken after 500 bytes, nginx will still happily serve this entity with a<br>
> 200 OK status.<br>
<br>
</div>Status code 200 is irrelevant - as it's generally not possible to<br>
know if connection will be broken in advance (i.e. before sending<br>
status).<br>
<div class="im"><br>
> This may be a known bug in nginx, I wanted to be certain I indeed understand<br>
> it correctly and raise the attention to it on the nginx mailing list -<br>
> because I think this is a very serious bug with potentially disastrous<br>
> consequences, as I describe below.<br>
><br>
> I was able to confirm this both for uwsgi_pass and proxy_pass; if the<br>
> upstream sets a Content-Length and then breaks the connection before that<br>
> length was achieved, nginx will pass this onwards to the client.<br>
> Furthermore, since the upstream protocol is HTTP 1.0 but the nginx-client<br>
> protocl is HTTP 1.1 (with keepalive), the request will simply not terminate,<br>
> because the client can't tell that the server has nothing more to send and<br>
> nginx will not break the connection, despite the fact its connection with<br>
> the upstream was broken and there's no chance this request will ever be<br>
> fulfilled.<br>
><br>
> Things get far worse with gzip compression on - nginx will remove the<br>
> Content-Length header sent by the client and replace it with chunked<br>
> encoding - /incorrect chunked encoding/, that will make the client believe<br>
> it has the full entity, even though it has only a part of this.<br>
<br>
</div>Yes, this is a known problem.  Upstream module expects backend to<br>
behave properly, and if it misbehaves (or, more importantly,<br>
connection is broken for some reason) bad things may happen.<br>
<br>
Upstream's module code needs carefull auditing to fix this.  It's<br>
somewhere in my TODO (though not very high).<br>
<br>
Maxim Dounin<br>
<br>
_______________________________________________<br>
nginx mailing list<br>
<a href="mailto:nginx@nginx.org">nginx@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx</a><br>
</blockquote></div><br></div></div>