Using JMeter's HTTP Header Manager
This blog post was updated for accuracy in July 2021.
In our last post, JMeter's Superpower: The HTTP Proxy Server, we discussed how to use the HTTP Proxy Server to record testing scenarios.
The HTTP Proxy Server automatically adds the HTTP Header Manager to each request. This manager is the magic lasso that contains and maintains the HTTP headers that are sent to the server from the browser in use for scenario recording.
Each time the browser sends a request to a server, headers with additional information are attached to the request. When documenting to the HTTP protocol, a large number of them are described. Still, a group with many used headers can be allocated: Accept-Language, Accept-Encoding, User-Agent, Referer.
Standard HTTP Headers look like this:
This header defines the language of the page that the browser prefers to receive in the response. In our case it means, that if server has the same resource in different languages, then after receiving the request, it will send the English variant of the page.
Is the Speed of Loading the Same Page for Different languages Different?
Choosing the right language for defined users may influence the performance of the whole system. And it is JMeter's task to determine such dependencies.
The accept-encoding header tells the server which coding method the server should select before sending the response to a client. In our case “gzip” and “deflate” are algorithms of compressing data before sending it to end user. There are more options related to Accept-Encoding (do a quick 'Google' for the description). In this scenario, take note that using data compression decreases the load on the network and increases the load on the CPU.
How Will This Influence Application performance?
To answer - let's test the same application with and without gzip and then compare response times.
If an Accept-Encoding field is present in a request, and if the server cannot send a response which is acceptable according to the Accept-Encoding header, then the server SHOULD send an error response with the 406 (Not Acceptable) status code.
If a NO Accept-Encoding field is present in a request, the server MAY assume that the client will accept any content coding. In this case, if "identity" is one of the available content-codings, then the server SHOULD use the "identity" content-coding, unless it has additional information that a different content-coding is meaningful to the client.
IT-technologies are in progress. This is the reason for the appearance of a large number of new devices that have access to Internet. iPhones, Android Phones, other smart phones, et. al. Each of these devices has its own browser. This issue has an enormous influence on the web development industry, because developers have to create different versions of the same page over again for each browser.
The User-Agent allows the defining of the type of client and receiving version of the page that will be correctly displayed in browser. Especially in cases where mobile applications are tested, this difference can be HUGE. Our testing scenario will be more realistic if we try to understand how many real users will run the certain version of any given browser and balance it with your JMeter test plan.
This field shows that this request was sent while switching from a certain page. And, the referer this page is specified. Why is it so important? Because some highly secure applications have different reactions for request from internal and external pages. For example, any request from an external page can be classified as suspicious, as a potential vulnerability for cross-site request forgery. For the performance testing process it means that if the referer will not be specified, the web-server can simply decline such request. So if you specify 'no refer' or 'invalid referer' then you can receive an invalid response with an incorrect response time. In many cases the response time is very brief, because the server doesn’t process such requests. And this will influence all the statistics of said test.
The Solution - The HTTP Header Manager
The Header Manager lets you add or override HTTP request headers. Let's examine this process using a test plan which was previously recorded with the HTTP Proxy Server.
The only interesting feature here is that the HTTP Header Manager allows the user to save headers to *.jmx file. But this file is not in an XML format as is the usual JMeter test plan. It contains plain text, as displayed below.
JMeter Supports Multiple Header Managers
The header entries are merged to form the list for the sampler. If an entry to be merged matches an existing header name, it replaces the previous entry, unless the entry value is empty in which case any existing entry is removed. This allows one to set up a default set of headers, and apply adjustments to particular samplers.
Using the HTTP Header Manager: Single Request, With the Thread Group, and Merging Two Header Managers in One Request
Let’s start with the single request. Create the following test plan using any preferred method.
Compare with the request result in View Results Tree.
Move the header manager to the top of thread group, as displayed below.
Check out the View Results Tree:
Yup- doesn't matter where the header manager is placed, headers in request are the same.
The last example will be more interesting, because it will show how JMeter merges headers from different managers.
Copy the header manager from the previous example to the sampler. The instance of the manager in the thread group has not been altered.
In the second manager the “Accept-Language” has been changed and a value was removed from “Accept-Encoding”.
Now run this request
JMeter has captured headers from the latest manager via the test plan, but nothing was altered in pre-existing headers.
Be careful now. Don't lose any more of your head.....ers.
Learn more about JMeter from our free Webinar "How to Make Performance Testing with JMeter Simple".