As per HTTP Request documentation
HTTP Request - this has an implementation drop-down box, which selects the HTTP protocol implementation to be used: Java - uses the HTTP implementation provided by the JVM. This has some limitations in comparison with the HttpClient implementations - see below. HTTPClient3.1 - uses Apache Commons HttpClient 3.1. This is no longer being developed, and support for this may be dropped in a future JMeter release. HTTPClient4 - uses Apache HttpComponents HttpClient 4.x. Blank Value - does not set implementationon HTTP Samplers, so relies on HTTP Request Defaults if present or on jmeter.httpsampler property defined in jmeter.properties The Java HTTP implementation has some limitations: There is no control over how connections are re-used. When a connection is released by JMeter, it may or may not be re-used by the same thread. The API is best suited to single-threaded usage - various settings are defined via system properties, and therefore apply to all connections. There is a bug in the handling of HTTPS via a Proxy (the CONNECT is not handled correctly). See Java bugs 6226610 and 6208335. It does not support virtual hosts.
It's better to use HTTPClient4
implementation.
However if you need your requests to be as much like a real browser as possible you need to consider using following components:
- In HTTP Request Defaults tell JMeter to retrieve all embedded resources and do in using thread pool of 2-5 requests (as real browsers do)
- Use HTTP Cookie Manager - to simulate browser cookies and to deal with cookie-based authentication
- Use HTTP Header Manager - to set user agent string, content type, accept language, etc. headers.
- Use HTTP Cache Manager - to simulate browser cache