We're using nginx 1.5.12 and 1.5.13 on Ubuntu 12.04 LTS via Azure VM.
Since last night, on both FireFox and Chrome, Windows and OSX, we're having difficulty with SPDY. If the browser cache is warm and proxy_cache is enabled, we see errors like this:
2014/04/09 05:26:29 [info] 17859#0: *6 SSL_write() failed (SSL:) (32: Broken pipe) while processing SPDY, client: my.ip, server: 0.0.0.0:443
On the client side, for instance in Chrome, we see:
t=1397021193179 [st= 386] SPDY_STREAM_ERROR
--> description = "ABANDONED (stream_id=13): https://bringyourbaygame.com/scripts/vendor/require.js"
--> status = -100
--> stream_id = 13
When this happens the request will be listed as Aborted (Firebug) or ERR_EMPTY_RESPONSE (Chrome) and the SSL_write info line is logged on nginx. No errors are logged. The site never finishes fully loading. Here's more of the Chrome net-internals: http://pastebin.com/gaGxZGBW
If the browser cache is cleared manually or disabled, the problem goes away. With proxy_cache off, the problem goes away. The cache config is:
proxy_cache_key $scheme$proxy_host$host$uri$is_args$args;
proxy_temp_path /mnt/proxy_temp 1 2;
proxy_cache_path /mnt/proxy_cache levels=1:2 keys_zone=czone:256m;
proxy_cache_valid any 20s;
proxy_cache_valid 200 5m;
proxy_cache czone;
Here is debug output from nginx: http://pastebin.com/tnm6PaL6
I'm thinking perhaps there is a race condition and the lack of caching fixes it by adding some latency?
If SPDY or caching is disabled, everything works fine. Things that don't help: disabling SSLv3, disabling gzip, ssl cache on/off, spdy_headers_comp 0/5, removing SNI (delete all but one server block). Yes, we updated OpenSSL and our certificates, but we tried with old certificates and the problem persists. Strangely, proxy_buffering off doesn't help (I thought since it disabled the cache, it'd have the same end effect).
Site is just reverse proxying; no local resources (there is a Lua script that is not hit, but we removed that and it made no difference).
How can I further debug this?
Hopefully,
-Michael
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
Since last night, on both FireFox and Chrome, Windows and OSX, we're having difficulty with SPDY. If the browser cache is warm and proxy_cache is enabled, we see errors like this:
2014/04/09 05:26:29 [info] 17859#0: *6 SSL_write() failed (SSL:) (32: Broken pipe) while processing SPDY, client: my.ip, server: 0.0.0.0:443
On the client side, for instance in Chrome, we see:
t=1397021193179 [st= 386] SPDY_STREAM_ERROR
--> description = "ABANDONED (stream_id=13): https://bringyourbaygame.com/scripts/vendor/require.js"
--> status = -100
--> stream_id = 13
When this happens the request will be listed as Aborted (Firebug) or ERR_EMPTY_RESPONSE (Chrome) and the SSL_write info line is logged on nginx. No errors are logged. The site never finishes fully loading. Here's more of the Chrome net-internals: http://pastebin.com/gaGxZGBW
If the browser cache is cleared manually or disabled, the problem goes away. With proxy_cache off, the problem goes away. The cache config is:
proxy_cache_key $scheme$proxy_host$host$uri$is_args$args;
proxy_temp_path /mnt/proxy_temp 1 2;
proxy_cache_path /mnt/proxy_cache levels=1:2 keys_zone=czone:256m;
proxy_cache_valid any 20s;
proxy_cache_valid 200 5m;
proxy_cache czone;
Here is debug output from nginx: http://pastebin.com/tnm6PaL6
I'm thinking perhaps there is a race condition and the lack of caching fixes it by adding some latency?
If SPDY or caching is disabled, everything works fine. Things that don't help: disabling SSLv3, disabling gzip, ssl cache on/off, spdy_headers_comp 0/5, removing SNI (delete all but one server block). Yes, we updated OpenSSL and our certificates, but we tried with old certificates and the problem persists. Strangely, proxy_buffering off doesn't help (I thought since it disabled the cache, it'd have the same end effect).
Site is just reverse proxying; no local resources (there is a Lua script that is not hit, but we removed that and it made no difference).
How can I further debug this?
Hopefully,
-Michael
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx