# Truncated output for css with nginx 1.2 **URL:** \ **Category:** NGINX\ **Created:** [May 16, 2012, 12:36am UTC](https://www.ruby-forum.com/t/truncated-output-for-css-with-nginx-1-2/219773 "2012-05-16T00:36:18Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![dubstep](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/cdc98d/32.png) [@dubstep](https://www.ruby-forum.com/u/dubstep)\ **Post date:** [May 16, 2012, 12:36am UTC](https://www.ruby-forum.com/t/truncated-output-for-css-with-nginx-1-2/219773/1 "2012-05-16T00:36:18Z")
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](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. Thanks Anand Posted at Nginx Forum: > **[Truncated output for css with nginx 1.2](https://forum.nginx.org/read.php?2,226477,226477#msg-226477)** > > 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... ---
**Author:** ![forforums](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/f/a5b964/32.png) [@forforums](https://www.ruby-forum.com/u/forforums)\ **Post date:** [May 16, 2012, 10:05am UTC](https://www.ruby-forum.com/t/truncated-output-for-css-with-nginx-1-2/219773/2 "2012-05-16T10:05:08Z")
Hello! On Tue, May 15, 2012 at 06:35:34PM -0400, forforums wrote: > 2012/05/15 21:33:48 [debug] 31832#0: \*216 event timer: 14, old: > 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 D.