Truncated output for css with nginx 1.2

[Maxim Dounin]

Hello!

On Tue, May 15, 2012 at 06:35:34PM -0400, forforums wrote:

> This is on centos and nginx 1.2.
> 
> I have a jetty server in the back and it is https all the way thru.
> Intermittently the browser hangs trying to read a css that the app is
> using. This file is about 30076 bytes and interestingly it always hangs
> at 16104 bytes. Now when I chomp the file down to 6k I have not been
> able to reproduce this problem!!
> 
> Jetty server returns a 200OK and 30076 bytes, but the logs in nginx
> shows 
> 
> 10.23.8.163 - - [15/May/2012:21:53:48 +0000] "GET /app/application.css
> HTTP/1.1" 200 16104 "https://loginlab.com/somesite" "Mozilla/5.0
> (Ubuntu; X11; Linux x86_64; rv:8.0) Gecko/20100101 Firefox/8.0" "-"
> "RC4-SHA" "-" 0.062 0.062 - OK
> 
> when this happens. So I build nginx with debug and turned on debug for
> the hosts involved and I get this for the case when the file is chopped
> 
> 2012/05/15 21:33:48 [debug] 31832#0: *216 http copy filter: 0
> "/idp/application.css?"
> 2012/05/15 21:33:48 [debug] 31832#0: *216 event timer: 14, old:
> 1337119428147, new: 1337119428195
> 2012/05/15 21:33:48 [debug] 31832#0: *216 http upstream request:
> "/app/application.css?"
> 2012/05/15 21:33:48 [debug] 31832#0: *216 http upstream dummy handler
> 2012/05/15 21:33:48 [debug] 31832#0: *216 http upstream request:
> "/app/application.css?"
> 2012/05/15 21:33:48 [debug] 31832#0: *216 http upstream process non
> buffered upstream
> 2012/05/15 21:33:48 [debug] 31832#0: *216 SSL_read: 1
> 2012/05/15 21:33:48 [debug] 31832#0: *216 SSL_read: 0
> 2012/05/15 21:33:48 [debug] 31832#0: *216 SSL_get_error: 5
> 2012/05/15 21:33:48 [debug] 31832#0: *216 peer shutdown SSL cleanly
> 
> Seems like read gets a SSL_ERROR_SYSCALL. Any pointers to what else I
> can look at to get to the bottom of this problem is much appreciated.

The log snippet suggests connection was closed by a upstream.  I 
would suggest to test that upstream response is correct and 
actually fully sent by the upstream.  It can be checked (more or 
less) from full debug log, but often it's simplier to either use 
openssl's command line client (to manually reproduce the request) 
and/or tcpdump/wireshark to check what happens on the wire 
(wireshark can dissect ssl traffic nicely, especially when private 
key is available).

Maxim Dounin