On Oracle JDK 1.8.0_72 64-bit, Kubuntu 15.10, JMeter 2.11-3 package from standard ubuntu repository.

Setup: 5 HTTP Request samplers which are configured identically other than the path (i.e. 5 different resources from the same server). "Use KeepAlive" is unchecked on all of them. For this test, the thread group is configured to use 1 thread and 1 loop (i.e. a single execution).

Expected behavior:
RFC 7230 section 6.6 states that
"A client that sends a "close" connection option MUST NOT send further
requests on that connection (after the one containing "close") and
MUST close the connection after reading the final response message
corresponding to this request."


So the expected behavior is that after each request the connection should be closed, and a new one created for the next request.

Important note: the server in this case is not sending a "Connection: close" header in the response - the RFC recommends it do so, but it is not required. I'm guessing this may affect the client behavior.

Actual Behavior:
All implementations correctly send the "Connection: close" header to the server, however what follows depends on the implementation:

- HttpClient 3 implementation works correctly.

- Java implementation sends a request with the close header, reads the response and immediately sends the next request on the same connection. The server ignores the second request and closes the connection (as it must according to the RFC). The client then opens a new connection and retries the second (failed) request from the previous connection, which now succeeds, reads the response and once again sends the request for the next (3rd) resource on the same connection, and so on until the end. So effectively, each connection contains the proper request + response plus an extra failed request which will be retried on a subsequent connection. This certainly affects performance during a load test, and is incorrect and unnecessary.

- HttpClient 4 implementation sends a request with the close header, reads the response and immediately sends the next request on the same connection, just like the Java implementation. The server ignores the second request and closes the connection (as it must according to the RFC). The client marks the second request as a failure, and opens a new connection in which it requests the next (3rd) request, etc. So effectively, every odd-numbered request succeeds, and every even-numbered request fails. This is a catastrophic failure of the client, which fails 50% of all requests.

In summary, 2 out of the 3 implementations don't handle connections properly when "Use KeepAlive" is unchecked, and the 3rd (HttpClient 3) functions correctly, but to my understanding it is deprecated and scheduled to be removed.