Multiple HTTP calls fail on the same connection #7
Comments
|
Some logging on the REST client sending HTTP GET and POST with WinFoom configured as a proxy server: |
|
You are absolutely right, and I had to assume this unwanted behavior since the application inception. The issue starts with the fact that a MITM(man-in-the-middle) piece of software like Winfoom cannot honor connection keep-alive HTTP directive for obvious reasons, hence the socket close action on each request. Fortunately this happens only at software level - behind the scene, there are some mechanisms to reuse connections (at OS level) - hence the performance doesn't drop. Since Keep-alive connections are enabled by default in HTTP/1.1 the only way to notify a client about the socket close action is by adding Connection: close header to override the default behavior. It would likely work, but I didn't try. |
|
Hi Eugen, That is a blazing fast response, thanks for your input in this matter. Unfortunately I don't have full control on the code of the REST client, so I can't change the behaviour on that side (i.e. remove the connection pooling or Keepalive headers). As I'm not very familiar with the WinFoom code yet, could you give me some hints were I can add the Connection: Close header, without affecting the HTTP connections to the actual endpoint? |
|
It is very simple to add, I will create a new branch and do it myself. I'll let you know when it's done |
|
I think I have found the right spot: |
|
Yes, you still have to remove the existent one contained by the response (if any). See test-connection-close branch, I have made the modification. Can you take from here? Otherwise I can make a pre-release for you. |
I can take it from there. Thank you very much! |
|
You welcome. Please let me know how it worked. |
|
Just made a maven build and did some testing: it works beautifully. Thanks again! |
|
If there are no side effects, I can merge it into master and make a new release. |
For my specific usecase there are no side effects. Ofcourse I did not do a full unit test on all the functionality. But I expect no side effects as the socket close was already in place: this only fixes the client behaviour about communicating the connection has been closed. |
|
I'll do some testing myself then issue a new release. Thanks for your interest in this project. |
|
You are welcome! Before making a release: I noticed that using encode() for the password within a JSON file is not being interpreted. I'll file a new issue for that. |
|
Solved in v4.0.3 |
Thank you for this excellent piece of software. It is very helpful to authenticate my Java REST client to an IIS server requiring NTLM authentication.
Bug description
When putting multiple requests on the same HTTP connection my HTTP REST client ends up with an IOException. My HTTP REST client is using Apache HTTP Client as well, and using WinFoom as a Proxy Server to handle NTLM authentication to a IIS Web Server. Therefore I'm using the HTTP proxy mode:
{
"proxyType" : "HTTP",
"proxyHost" : "172.16.1.10",
"proxyPort" : 8020,
"proxyUsername" : "web-user",
"proxyPassword" : "*******",
"localPort" : 3129,
"proxyTestUrl" : "http://example.com",
"httpAuthProtocol" : "NTLM"
}
my HTTP REST client is also using a shared connection manager with a PoolingHttpClientConnectionManager. What I see is that the initial request is from my REST client is working fine, but the subsequent request on the same connection fails with an IOException. When doing the second request I noticed that WinFoom has already closed the socket, without informing the requester (my REST client)
I.e. Im doing a HTTP GET followed by a HTTP POST on the samen connection. When running WinFoom in debug mode I clearly see that he socket is already closed, after the first HTTP GET. I suspect that the socket is closed without informing my REST client, so therefore it assumes the HTTP connection is still open.
To Reproduce
Steps to reproduce the behaviour:
Log
Notice that no logging is being done for the HTTP POST as the socket is closed, without informing the client.
Context information:
The text was updated successfully, but these errors were encountered: