JMeter HTTP Request Sampler
There are many samplers that JMeter provides but I am willing to bet that the HTTP Request samplers is the most frequently used and, in this Blog Post, we are going to look at how this works and how it can be configured.
HTTP Request¶
Before we look at the sampler lets look at the option available to us in the HTTP Request drop down, while you probably don’t need to understand these in order to test you application using JMeter it can be useful.
These request methods indicate the action to be taken on the resource specified in the Web Server section of the sampler and are sometimes referred to as HTTP verbs, these are defined by The World Wide Web Consortium (W3C). W3C is the main international standards organisation for the World Wide Web.
There are 5 main methods used in modern API’s these are:
| Method | Description |
|---|---|
| GET | The GET method requests a representation of the specified resource. Requests using GET should only retrieve data. |
| PATCH | The PATCH method is used to apply partial modifications to a resource. |
| POST | The POST method is used to submit an entity to the specified resource, often causing a change in state or side effects on the server. |
| PUT | The PUT method replaces all current representations of the target resource with the request payload. |
| DELETE | The DELETE method deletes the specified resource. |
There are also methods widely used elsewhere
| Method | Description |
|---|---|
| HEAD | The HEAD method asks for a response identical to that of a GET request, but without the response body. |
| OPTIONS | The OPTIONS method is used to describe the communication options for the target resource. |
| TRACE | The TRACE method performs a message loop-back test along the path to the target resource. |
In addition to the above JMeter offers the ability to use these WebDAV methods.
WebDAV (Web Distributed Authoring and Versioning) is an extension of the Hypertext Transfer Protocol (HTTP) that allows clients to perform remote Web content authoring operations..
| Method | Description |
|---|---|
| PROPFIND | Retrieve properties, stored as XML, from a web resource. It is also overloaded to allow one to retrieve the collection structure (also known as directory hierarchy) of a remote system. |
| PROPPATCH | Change and delete multiple properties on a resource in a single atomic act. |
| MKCOL | Create collections (also known as a directory). |
| COPY | Copy a resource from one uniform resource identifier (URI) to another. |
| MOVE | Move a resource from one URI to another. |
| LOCK | Put a lock on a resource. WebDAV supports both shared and exclusive locks. |
| UNLOCK | Remove a lock from a resource. |
| REPORT | Obtains information about a resource. |
| MKCALENDAR | Creates a new calendar collection resource. |
| SEARCH | The SEARCH method is used to initiate a server-side search. |
HTTP Sampler¶
Now we understand what type of requests we can make let’s start by looking at the sampler and some of the key concepts:
Web Server¶
Let’s start with the Web Server section which is straightforward; you pass your applications
- Protocol
- Server Name or IP
- Port Number
These will be easy enough to find out from your development team or system administrator, if the port is the standard HTTP port of 80 you can leave the Port Number field blank as it is implied.
HTTP Request¶
Let’s move on to the HTTP Request section where we provide one of the methods that we have already discussed above along with the Path.
The Path will be the location of the resource on the server that you are targeting.
If we take the OctoPerf web site as an example and look at the Blog Post page, the main page is located at https://blog.octoperf.com/
This is an example of one of the Blog Post that can be found, https://blog.octoperf.com/jmeter-http-request-sampler/
So, to create a HTTP Sampler that will return these pages you would have these values in your sampler.
The content encoding is a little misleading as this relates to the is the character encoding to be used and is not related to the Content-Encoding HTTP header, if left blank JMeter uses UTF8.
Request Values¶
Before we move onto the more advanced features of the HTTP Request sampler it is a good idea to get to grips with the section that is marked with - Parameters - Body Data - Files Upload
Let’s look at each one in turn.
Parameters¶
These vary depending on the method you are using, if you are using a POST or PUT request then the values you enter will be sent as form data to the specified URL in a separate request if you are using GET or DELETE then the values are sent as query string appended to the URL.
If your value contains characters such as the following, then encoding is usually required:
- ASCII Control Chars,
- Non-ASCII characters,
- Reserved characters,
- Unsafe characters.
As you can see in our example above, we are passing a URL as a parameter therefore we need to encode it.
The Content-Type is fairly straightforward and is the type of parameter you are sending and a comprehensive list of all content types can be found here.
If you have a name and you are not passing a value, then you probably will need to uncheck the Include Equals? Checkbox although this does depend on the way your server handles it. Sometimes it does not matter although unchecking if you are sending an empty value is a good practise.
Body Data¶
If you are sending a piece of JSON for example to a server resource then this is the best way. The other being as a parameter which is not particularly legible, then you do this in the Body Data section.
It is worth noting that if you have a value in either the Parameters or the Body Data tabs then the other cannot be selected.
File Upload¶
Files Upload is straightforward and takes a path to a file that you want to send to a web server, if you provide a value in the parameter field, we discussed Parameters in the section above, then the file is sent as a value of the parameter. If the parameter field is blank then the file contents are sent as the body of the request which we also discussed above.
There is a field called MIME Type that according to the JMeter documentation
MIME type (for example, text/plain). If it is a POST or PUT or PATCH request and either the 'name' attribute (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.
Which basically is the encoding type for the file you are sending, and a comprehensive list can be found here.
Other Request Options¶
These are:
- Redirect Automatically
- Follow Redirects
- Use KeepAlive
- Use multipart.form-data
- Browse-compatible headers
Now it is easy to just copy and paste what the JMeter documentation says which is:
Redirect Automatically: This option will check if the response of the server is a redirection. If this is true, it will redirect to this URL.
Follow redirects: This option will also check if the response of the server is a redirection. If this is true, it will also redirect to the URL. The difference from the first redirect (Redirect Automatically) is that Redirect Automatically will not consider each redirect as a separate request, while Follow Redirects does.
Use KeepAlive: Sets the connection value to KeepAlive as the request header.
Use multipart/form-data: Sets the Content-type value to multipart/form-data as the request header.
Browser-compatible headers: When using multipart/form-data, this option suppresses the Content-Type and Content-Transfer-Encoding headers; so only the Content-Disposition header is sent.
The reality is that it is unlikely that you will have to determine this yourself, if you are manually building samplers then you will have access to, or be embedded in, your development teams and therefore will know what these values should be, for information the HTTP Sampler defaults to Follow Redirects and Use KeepAlive.
For instance, disabling the keepalive will generate a new TCP connexion for every request, a single user browsing several pages on your application would not behave in that way. But if you're testing an API it can make sense to change this setting.
Advanced Tab¶
The advanced tab contains several very useful settings which are worth investigating.
Client Implementation and Timeouts¶
These are discussed together as timeouts depends on the value set in implementation.
The implementation is either Java or HTTPClient4, if left blank then the value of the property jmeter.httpsampler is used. The difference between these two implementation is the HTTP engine used to send this request:
- Java means the default engine from the JVM is used,
- HTTPClient4 means the Apache HttpComponents HttpClient 4 is used.
The timeouts are values in milliseconds for both connection and response and are ignored if the implementation is not explicitly set to HTTPClient4.
Embedded Resources and URL’s Must Match¶
If you have the Retrieve All Embedded Resources checkbox enabled then JMeter will parse the HTML and send separate requests for all images, Java applets, JavaScript files, CSSs, etc. You can configure how many parallel threads should be used to that end with the option next to it:
The URL’s must match is only used if the Retrieve All Embedded Resources is checked and allows you to specify which resources you want to retrieve based on a regular expression.
So, if we only wanted to download images from a certain blog post we may set this value to https://blog.octoperf.com/jmeter-http-request-sampler/.*
(litteraly our blog post URL followed by any character but end of line)
It is important to note 2 things about this option:
- It has a significant impact on memory and CPU used by JMeter since it requires loading the entire response in memory and sending a request for each match found,
- It can only work on the response for this request, meaning it is not a recursive search. For instance if some images are referenced in a CSS file that is fetched by this option they will not be fetched unless you also add another request to this CSS file and activate this option on it.
Source Address¶
The source address fields are used for IP Spoofing, if you are unfamiliar with the concept then imagine you have an application that as part of its authentication requires the IP Address of the machine the request is coming from and only allows one connection request per IP address.
When injecting load from either your local machine or a load injector all requests will have the same IP Address. IP Spoofing is a way of providing a set of IP Address values that can be used for each request to simulate users from different machines.
For this to work the test client must have multiple IP addresses set up and is discussed further here.
This is quite a niche subject and is worth a blog post therefore we will not delve any deeper here. Mostly because modern load balancers do not use the source Address as a criteria anymore.
Proxy Server¶
Some applications, especially around their authentication require all requests go through a proxy server where the heavy lifting associated with authentication, as an example, can be done. If this is the case in your application under test, you can define these settings here.
This can also be especially useful for debugging purpose, typically you can use this to send your JMeter request through a 3rd party tool like fiddler in order to double check it is properly formed. Especially when dealing with special/reserved characters or with unicode characters.
Optional Tasks¶
Under optional tasks is a single option, Save Response as MD5 hash. Essentially if your request returns a significant amount of data you may want to return a hash value to allow you to check, using a MD5 Assertion, your response rather than querying a large response payload.
This option vastly reduces the amount of memory consumed by JMeter since instead of loading the entire response content in-memory you will only load the hash. On the other hand you will lose the possibility to extract values from the response since it is not stored at all.
Complimentary samplers¶
The samplers below are often used in conjunction with a HTTP Request sampler and are worth including, we will not take an in-depth look at these but provide an overview of their uses.
HTTP Request Defaults¶
If all your HTTP Samplers use the same Protocol, Server, and Port then you can use a HTTP Request Defaults sampler to specify them in one place.
If we set our HTTP Request Defaults with these values.
We can leave these values in our HTTP Request samplers blank, and these values will be used.
It is worth noting that the HTTP Requests Default sampler contains all the setting we have been discussing, except for File Upload, allowing us to set any of these globally and not have to repeat on each sampler.
HTTP Cookie Manager¶
If you want to manage cookies created as part of the script execution it is enough to just add a HTTP Cookie Manager and this will manage these for you.
There are a few other options along with the ability to specify a user define Cookie but as discussed we will not look at this sampler in detail.
HTTP Header Manager¶
Header that are sent with HTTP Requests are import and most requests will not be successful without the correct values being set.
A comprehensive list of headers can be found here.
Conclusion¶
We have in this post discussed the HTTP Request sampler and the many options that are available, it is unlikely that you will use all of these but an appreciation of them is useful. Especially since they can have unexpected consequences on JMeter's performance or the relevance of your tests.