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

Server NGINX
1

I’ve discovered what I believe to be a bug (yeah I know everyone is
already
rolling their eyes) :smiley:

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.

Posted at Nginx Forum:

2

Hello!

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

HTTP/1.1 200 OK^M
Content-Type: text/x-json^M
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 D.