Content-Length ###s being served, but no actual content

[Maxim Dounin]

Hello!

On Wed, Feb 13, 2013 at 01:54:08PM -0500, tsaavik wrote:

> I've discovered what I believe to be a bug (yeah I know everyone is already
> rolling their eyes) :D
> 
> I believe that my CGI is returning some data (perhaps Content-Type header)
> and then is occasionally stalling due to backend load.
> This is fine, and fastcgi_read_timeout can be adjusted to deal with the
> issue of course.
> However, it appears that when Nginx times out the connection it still serves
> a non-empty Content-Length!
> 
> HTTP/1.1 200 OK^M
> Server: nginx/1.2.6^M
> Date: Tue, 05 Feb 2013 20:12:31 GMT^M
> Content-Type: text/x-json^M
> Content-Length: 397^M             
> Connection: keep-alive^M
> X-WSL-Version: 1.0^M
> ^M
> HTTP/1.1 200 OK^M
> Server: nginx/1.2.6^M
> Date: Tue, 05 Feb 2013 20:12:38 GMT^M
> Content-Type: text/x-json^M
> Content-Length: 396^M
> Connection: keep-alive^M
> ^M
> (There is actual JSON data here, I clipped it out, trust me!)
> 
> ----
> See that 397 bytes of non-existent data?
> I tested on nginx/0.8.53 and nginx/1.2.6. I'm using netcat6 to run the tests
> with http-pipelining.
> I also tried various different kernels, and ran the tests on my local
> network to rule out weird internet stuff.

Here nginx just returns Content-Length it got from the backend, 
and there is no way to withdraw headers if the problem with 
backend happens after headers are sent.  

What is wrong here is that next pipelined request is answered if 
error happens while reading response body from the backend.  
Instead, client connection should be just closed as there is no 
way to recover.

This is somewhat known problem and it's resolution waits for the 
upstream module error handling audit.  It's relatively low 
priority though as it doesn't appear frequently, as the problem 
have to happen after headers are sent, during transmission of a 
response body.

-- 
Maxim Dounin
http://nginx.com/support.html