Fwd: Problems with SSL + SPDY cause CLOSE_WAIT connections
Valentin V. Bartenev
vbart at nginx.com
Tue Sep 10 14:29:03 UTC 2013
On Tuesday 10 September 2013 15:00:30 Salvador Gironès Gil wrote:
> Hi,
>
> I know this appeared some time ago with first versions of SPDY, but we have
> been using 1.4.1 SPDY in production and it is generating lots of CLOSE_WAIT
> connections.
>
> Doing some testing, I found reproducible steps and a possible patch.
>
> Our env (listing what I think are relevant points, please ask for more if
> you need it):
> 1. Nginx 1.4.1
> 2. SSL + SPDY
> 3. Proxy-pass 443 port to a Rails app
> 3. Sendfile on
>
> Steps to reproduce:
> 1. Perform a POST with a big body (I'm uploading a file)
> 2. Refresh the browser before the upload finishes
> 3. Close the browser
>
> When the connection is closed due the browser close, the error.log (with
> debug enabled) says:
> *2013/09/10 10:02:53 [info] 4372#0:* *12 client closed prematurely
> connection while processing SPDY, client: 1.2.3.4, server: 0.0.0.0:443
> *2013/09/10 10:02:53 [debug] 4372#0:* *12 http reading blocked
>
> And nothing else happens.
>
> I tried to add a connection check inside *ngx_http_block_reading *based on
> * ngx_http_test_reading:*
>
>
> #if (NGX_HTTP_SPDY)
>
> if (r->spdy_stream) {
>
> if (c->error) {
> err = 0;
>
> goto closed;
> }
>
> return;
> }
> #endif
[..]
No, it is just wrong place to fix. The right patch looks like this:
diff -r 50f065641b4c src/http/ngx_http_spdy.c
--- a/src/http/ngx_http_spdy.c Wed Jul 17 16:51:21 2013 +0400
+++ b/src/http/ngx_http_spdy.c Tue Sep 10 18:24:41 2013 +0400
@@ -1204,6 +1204,7 @@ ngx_http_spdy_state_data(ngx_http_spdy_c
}
if (rb->post_handler) {
+ r->read_event_handler = ngx_http_block_reading;
rb->post_handler(r);
}
}
@@ -2604,6 +2605,9 @@ ngx_http_spdy_read_request_body(ngx_http
r->request_body->post_handler = post_handler;
+ r->read_event_handler = ngx_http_test_reading;
+ r->write_event_handler = ngx_http_request_empty_handler;
+
return NGX_AGAIN;
}
> I'm checking if the spdy_stream is open before trying to read from it. It
> converts the CLOSE_WAIT connections to TIME_WAIT and they do finalize after
> some seconds.
>
> I dig into nginx code yesterday, so I'm far from correctly understand where
> the real problem is, but this "patch" seems reasonable to me.
>
> Can someone with better nginx source code understanding, provide some
> feedback?
>
> And thanks for all your work!
Thank you for the report. Please, try the patch above.
wbr, Valentin V. Bartenev
More information about the nginx-devel
mailing list