Hi All,
In some testing we've been doing we've come across and issue with the HttpClient (Vertx 2.1), well in reality it's with the Netty stack.
The problem is with an SSL connection to a server that uses Connection: close in the response and doesn't put the content length.
So we have some Jetty servers (Dropwizard) fronted by haproxy fronted by Stunnel.
In the haproxy settings we have the option
http-server-close on this removes persistent connections (I know this was a naive set up on our part) but it highlighted the issue.
This option adds the 'Connection: close' header on the request to Jetty and Jetty responds with 'Connection: close' and no Content-Length (which as I understand it, is what is is entitled to do as per the spec)
The netty client doesn't get the LastHttpContent when this combination is used and will hang for the length of the request timeout. I believe it's related to this post
https://groups.google.com/forum/#!msg/vertx/4MOMDpoqCn0/eVMocDPSWE8J and perhaps this issue
https://github.com/netty/netty/issues/1952Anyway it's fairly easy to reproduce if we remove the haproxy and put the header directly on the HttpClientRequest.
As a test I used the latest version of the ning asynchttpclient (which uses the same version of Netty) and this had the same issue.
There are a couple of workarounds:
- Obviously remove the http-server-close option from haproxy (although this will only work for requests where Jetty doesn't put the 'Connection: close' header
- Never put that header on the request from HttpClient for SSL
- Add the TIMEOUTclose=0 option to stunnel (this is to fix a similar issue in MSIE but it work consistently here)
I tested 4.0.19.Final and 4.0.20.Final-SNAPSHOT of netty and the problem was still there; so no quick fix in updating netty :(
Anyway if you get hanging connections from the HttpClient then it may be this.
Peter