In the last article, we discussed about Samplers, sampler usage and many more . In case if you have missed click here. In this article, We will discuss about the most important and frequently used sampler i.e “HTTP Request Sampler”.
HTTP Request Sampler
This sampler lets you send an HTTP/HTTPS request to a web server. It also lets you control whether or not JMeter parses HTML files for images and other embedded resources and sends HTTP requests to retrieve them. The following types of embedded resource are retrieved:
- external scripts
- frames, iframes
- background images (body, table, TD, TR)
- background sound
The default parser is htmlparser. This can be changed by using the property “htmlparser.classname” – see jmeter.properties for details.
If you are going to send multiple requests to the same web server, consider using an HTTP Request Defaults Configuration Element so you do not have to enter the same information for each HTTP Request.
Or, instead of manually adding HTTP Requests, you may want to use JMeter’s HTTP(S) Test Script Recorder to create them. This can save you time if you have a lot of HTTP requests or requests with many parameters.
There are two different screens for defining the samplers:
- AJP/1.3 Sampler – uses the Tomcat mod_jk protocol (allows testing of Tomcat in AJP mode without needing Apache httpd) The AJP Sampler does not support multiple file upload; only the first file will be used.
- 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.
Note: the FILE protocol is intended for testing purposes only. It is handled by the same code regardless of which HTTP Sampler is used.
If the request requires server or proxy login authorization (i.e. where a browser would create a pop-up dialog box), you will also have to add an HTTP Authorization Manager Configuration Element. For normal logins (i.e. where the user enters login information in a form), you will need to work out what the form submit button does, and create an HTTP request with the appropriate method (usually POST) and the appropriate parameters from the form definition. If the page uses HTTP, you can use the JMeter Proxy to capture the login sequence.
In versions of JMeter up to 2.2, only a single SSL context was used for all threads and samplers. This did not generate the proper load for multiple users. A separate SSL context is now used for each thread. To revert to the original behaviour, set the JMeter property:
By default, the SSL context is retained for the duration of the test. In versions of JMeter from 2.5.1, the SSL session can be optionally reset for each test iteration. To enable this, set the JMeter property:
Note: this does not apply to the Java HTTP implementation.
JMeter defaults to the SSL protocol level TLS. If the server needs a different level, e.g. SSLv3, change the JMeter property, for example:
JMeter also allows one to enable additional protocols, by changing the property https.socket.protocols .
If the request uses a technique called “URL Rewriting” to maintain sessions, then see section 6.1 Handling User Sessions With URL Rewriting for additional configuration steps.
|Name||Descriptive name for this sampler that is shown in the tree.||No|
|Server||Domain name or IP address of the web server. e.g. http://www.example.com. [Do not include the http:// prefix.] Note: in JMeter 2.5 (and later) if the “Host” header is defined in a Header Manager, then this will be used as the virtual host name.||Yes, unless provided by HTTP Request Defaults|
|Port||Port the web server is listening to. Default: 80||No|
|Connect Timeout||Connection Timeout. Number of milliseconds to wait for a connection to open.||No|
|Response Timeout||Response Timeout. Number of milliseconds to wait for a response. Note that this appplies to each wait for a response. If the server response is sent in several chunks, the overall elapsed time may be longer than the timeout. A Duration Assertion can be used to detect overlong responses.||No|
|Server (proxy)||Hostname or IP address of a proxy server to perform request. [Do not include the http:// prefix.]||No|
|Port||Port the proxy server is listening to.||No, unless proxy hostname is specified|
|Username||(Optional) username for proxy server.||No|
|Password||(Optional) password for proxy server. (N.B. this is stored unencrypted in the test plan)||No|
|Implementation||Java, HttpClient3.1, HttpClient4. If not specified (and not defined by HTTP Request Defaults), the default depends on the value of the JMeter property
|Protocol||HTTP, HTTPS or FILE. Default: HTTP||No|
|Method||GET, POST, HEAD, TRACE, OPTIONS, PUT, DELETE, PATCH (not supported for JAVA implementation)||Yes|
|Content Encoding||Content encoding to be used (for POST, PUT, PATCH and FILE). This the the character encoding to be used, and is not related to the Content-Encoding HTTP header.||No|
|Redirect Automatically||Sets the underlying http protocol handler to automatically follow redirects, so they are not seen by JMeter, and thus will not appear as samples. Should only be used for GET and HEAD requests. The HttpClient sampler will reject attempts to use it for POST or PUT. Warning: see below for information on cookie and header handling.||No|
|Follow Redirects||This only has any effect if “Redirect Automatically” is not enabled. If set, the JMeter sampler will check if the response is a redirect and follow it if so. The initial redirect and further responses will appear as additional samples. The URL and data fields of the parent sample will be taken from the final (non-redirected) sample, but the parent byte count and elapsed time include all samples. The latency is taken from the initial response (versions of JMeter after 2.3.4 – previously it was zero). Note that the HttpClient sampler may log the following message:
“Redirect requested but followRedirects is disabled”
This can be ignored.
In versions after 2.3.4, JMeter will collapse paths of the form ‘/../segment’ in both absolute and relative redirect URLs. For example http://host/one/../two => http://host/two. If necessary, this behaviour can be suppressed by setting the JMeter property
|Use KeepAlive||JMeter sets the Connection: keep-alive header. This does not work properly with the default HTTP implementation, as connection re-use is not under user-control. It does work with the Apache HttpComponents HttpClient implementations.||No|
|Use multipart/form-data for HTTP POST||Use a multipart/form-data or application/x-www-form-urlencoded post request||No|
|Browser-compatible headers||When using multipart/form-data, this suppresses the Content-Type and Content-Transfer-Encoding headers; only the Content-Disposition header is sent.||No|
|Path||The path to resource (for example, /servlets/myServlet). If the resource requires query string parameters, add them below in the “Send Parameters With the Request” section.As a special case, if the path starts with “http://” or “https://” then this is used as the full URL. In this case, the server, port and protocol fields are ignored; parameters are also ignored for GET and DELETE methods. Also please note that the path is not encoded – apart from replacing spaces with %20 – so unsafe characters may need to be encoded to avoid errors such as URISyntaxException.||Yes|
|Send Parameters With the Request||The query string will be generated from the list of parameters you provide. Each parameter has a name and value , the options to encode the parameter, and an option to include or exclude an equals sign (some applications don’t expect an equals when the value is the empty string). The query string will be generated in the correct fashion, depending on the choice of “Method” you made (ie if you chose GET or DELETE, the query string will be appended to the URL, if POST or PUT, then it will be sent separately). Also, if you are sending a file using a multipart form, the query string will be created using the multipart form specifications. See below for some further information on parameter handling.Additionally, you can specify whether each parameter should be URL encoded. If you are not sure what this means, it is probably best to select it. If your values contain characters such as the following then encoding is usually required.:
|File Path:||Name of the file to send. If left blank, JMeter does not send a file, if filled in, JMeter automatically sends the request as a multipart form request.If it is a POST or PUT or PATCH request and there is a single file whose ‘Parameter name’ attribute (below) is omitted, then the file is sent as the entire body of the request, i.e. no wrappers are added. This allows arbitrary bodies to be sent. This functionality is present for POST requests after version 2.2, and also for PUT requests after version 2.3. See below for some further information on parameter handling.||No|
|Parameter name:||Value of the “name” web request parameter.||No|
|MIME Type||MIME type (for example, text/plain). If it is a POST or PUT or PATCH request and either the ‘name’ atribute (below) are omitted or the request body is constructed from parameter values only, then the value of this field is used as the value of the content-type request header.||No|
|Use as monitor||For use with the Monitor Results listener.||No|
|Save response as MD5 hash?||If this is selected, then the response is not stored in the sample result. Instead, the 32 character MD5 hash of the data is calculated and stored instead. This is intended for testing large amounts of data.||No|
|Embedded URLs must match:||If present, this must be a regular expression that is used to match against any embedded URLs found. So if you only want to download embedded resources from http://example.com/, use the expression: http://example\.com/.*||No|
|Use concurrent pool||Use a pool of concurrent connections to get embedded resources.||No|
|Size||Pool size for concurrent connections used to get embedded resources.||No|
|Source address type||[Only for HTTP Request with HTTPClient implementation]
To distinguish the source address value, select the type of these:
|Source address field||[Only for HTTP Request with HTTPClient implementation]
Override the default local IP address for this sample. The JMeter host must have multiple IP addresses (i.e. IP aliases, network interfaces, devices). The value can be a host name, IP address, or a network interface device such as “eth0” or “lo” or “wlan0”.
If the property httpclient.localaddress is defined, that is used for all HttpClient requests.
Note: when using Automatic Redirection, cookies are only sent for the initial URL. This can cause unexpected behaviour for web-sites that redirect to a local server. E.g. if http://www.example.com redirects to http://www.example.co.uk. In this case the server will probably return cookies for both URLs, but JMeter will only see the cookies for the last host, i.e. http://www.example.co.uk. If the next request in the test plan uses http://www.example.com, rather than http://www.example.co.uk, it will not get the correct cookies. Likewise, Headers are sent for the initial request, and won’t be sent for the redirect. This is generally only a problem for manually created test plans, as a test plan created using a recorder would continue from the redirected URL.
For the POST and PUT method, if there is no file to send, and the name(s) of the parameter(s) are omitted, then the body is created by concatenating all the value(s) of the parameters. Note that the values are concatenated without adding any end-of-line characters. These can be added by using the __char() function in the value fields. This allows arbitrary bodies to be sent. The values are encoded if the encoding flag is set (versions of JMeter after 2.3). See also the MIME Type above how you can control the content-type request header that is sent.
For other methods, if the name of the parameter is missing, then the parameter is ignored. This allows the use of optional parameters defined by variables. (versions of JMeter after 2.3)
Since JMeter 2.6, you have the option to switch to Post Body when a request has only unnamed parameters (or no parameters at all). This option is useful in the following cases (amongst others):
- GWT RPC HTTP Request
- JSON REST HTTP Request
- XML REST HTTP Request
- SOAP HTTP Request
Note that once you leave the Tree node, you cannot switch back to the parameter tab unless you clear the Post Body tab of data.
In Post Body mode, each line will be sent with CRLF appended, apart from the last line. To send a CRLF after the last line of data, just ensure that there is an empty line following it. (This cannot be seen, except by noting whether the cursor can be placed on the subsequent line.)
Figure 1 – HTTP Request with one unnamed parameter
Figure 2 – Confirm dialog to switch
Figure 3 – HTTP Request using Body Data
The POST, PUT and PATCH request methods work similarly, except that the PUT and PATCH methods do not support multipart requests or file upload. The PUT and PATCH method body must be provided as one of the following:
- define the body as a file with empty Parameter name field; in which case the MIME Type is used as the Content-Type
- define the body as parameter value(s) with no name
- use the Post Body tab
If you define any parameters with a name in either the sampler or Http defaults then nothing is sent. PUT and PATCH require a Content-Type. If not using a file, attach a Header Manager to the sampler and define the Content-Type there. The GET and DELETE request methods work similarly to each other.
Upto and including JMeter 2.1.1, only responses with the content-type “text/html” were scanned for embedded resources. Other content-types were assumed to be something other than HTML. JMeter 2.1.2 introduces the a new property HTTPResponse.parsers , which is a list of parser ids, e.g. htmlParser and wmlParser . For each id found, JMeter checks two further properties:
- id.types – a list of content types
- id.className – the parser to be used to extract the embedded resources
See jmeter.properties file for the details of the settings. If the HTTPResponse.parser property is not set, JMeter reverts to the previous behaviour, i.e. only text/html responses will be scanned
If you enjoy reading article then you can subscribe our updates for FREE, just add your email id . I will keep on updating the article for latest testing information. Subscribe and stay tuned for updates, there’s lot more to come.
🙂 Happy Performance Testing !! 🙂