Strange prepending of 0 to response

Hi All,

Sorry that my first posting here is a support request/bug report, but
I’ve gotta start somewhere!

So - basically, we’re seeing responses occasionally (not always - in
fact, quite infrequently) coming back with a 0 prepended to the entire
response - before the headers.

This means that the response received by the browser ends up looking
like


0

HTTP/1.1 200 OK
Server: nginx/0.8.53
Date: Tue, 01 Feb 2011 09:07:27 GMT
Content-Type: text/html; charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive
Set-Cookie: blu-session-id=2baf936adc11f79aad72827d46fd31aa; path=/;
HttpOnly
Expires: Mon, 1 Jan 2001 00:00:00 GMT
Last-Modified: Tue, 01 Feb 2011 09:07:27 GMT
Cache-Control: no-store, no-cache, must-revalidate, max-age=0,
post-check=0, pre-check=0
Pragma: no-cache
p3p: CP=“IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND
CNT”
Content-Encoding: gzip

and then a load of gzip’d data.


This of course breaks all sorts of behaviour. We initially thought it
was coming from HttpProxyModule, however after reconfiguring to serve
certain assets directly from disk, rather than via the proxy, we saw the
same issue repeating itself, meaning that it’s probably independent from
the proxy module.

Has anyone seen this behaviour before? Any ideas on where it’s coming
from?

Thanks in advance!

Maxwell

You’re absolutely correct - I’ve just applied the patch, rebuilt, run
through a few million requests, and it’s no longer happening.

Thanks so much!

Maxwell

Hello!

On Tue, Feb 01, 2011 at 10:14:19AM +0000, Maxwell Lamb wrote:

looking like
Set-Cookie: blu-session-id=2baf936adc11f79aad72827d46fd31aa; path=/; HttpOnly
This of course breaks all sorts of behaviour. We initially
thought it was coming from HttpProxyModule, however after
reconfiguring to serve certain assets directly from disk, rather
than via the proxy, we saw the same issue repeating itself,
meaning that it’s probably independent from the proxy module.

Has anyone seen this behaviour before? Any ideas on where it’s
coming from?

This looks like duplicate last chunk (“0” CRLF CRLF) in previous
request. There is at least one known problem with proxy_cache
(with proxy_cache_use_stale) which results in such behaviour.

If you use proxy_cache you may test if switching it off (or at
least disabling proxy_cache_use_stale completely) resolves the
problem. Alternatively, apply patch from here:

http://nginx.org/pipermail/nginx-devel/2010-January/000102.html

Maxim D.