Lee Hinman

Revisiting this, I'm not sure clj-http should attempt to do anything in this case, I think it's a legitimate exception that is thrown and should be caught by the user...

Okay, I'm reopening this to look into it more. For reference, here's the RFC mentioning this: ``` An HTTP/1.1 (or later) client sending a message-body SHOULD monitor the network connection...

Also, I was able to reproduce this on a server other than http-kit, so I'm glad it's not dependent on that.

@bladealslayer after some more research, I found a couple of things: It's known that Apache does this, it's unfortunately a lose-lose situation: - If the server closes the socket it...

I looked into this, it turns out that the error we both receive is due to a misconfigured HTTP server, see - https://issues.apache.org/jira/browse/HTTPCLIENT-1522 - https://stackoverflow.com/questions/7615645/ssl-handshake-alert-unrecognized-name-error-since-upgrade-to-java-1-7-0 The solution for this is...

@timvisher I do think connection managers should be easier to build, I'd say probably 8 out of the last 10 issues people have requested have been something related to them...

> Ah, is it the use of SSLSocketFactory/STRICT_HOSTNAME_VERIFIER vs. BrowserCompatHostnameVerifier? Could you explain what the difference is? Yep, that's it. Basically the default hostname verifier will not verify something like...

Hi All, I just released clj-http 3.0.0, this is a huge change am I'm sure there are bugs, but please do give it a try and open issues (or PRs,...

Unfortunately clj-http 3.0.0 requires JDK8, so I'm not sure if this still applies also?

Actually, I made a mistake with [cheshire](https://github.com/dakrone/cheshire/pull/101) so I have released 3.0.1 that should be plenty compatible with earlier Java versions. @timvisher I haven't come up with a changelog quite...