Blog
April 15, 2021
Modern web-applications are becoming more complex each day, and almost every website uses cookies to store at least some user information. The most common usage is for storing user session information. Apache JMeter™ has a powerful config element, the HTTP Cookie Manager, to handle the storing automatically. At the same time, the JMeter Cookie Manager also has a lot of features and properties for handling other tasks as well. Some of the advanced uses of the JMeter Cookie Manager will be described in this blog post.
This is the second blog post about the HTTP Cookie Manager.
Create a Basic Script With the JMeter Cookie Manager
Let’s start by creating a short script that will show the capabilities of the Cookie Manager config element. The BlazeDemo website was chosen to run our load test. You can use it, too.
🚀Try BlazeMeter today for JMeter testing at scale >>
The login page of this website contains two cookies with the responses ‘XSRF-TOKEN’ and ‘laravel_session’. You can use the element inspector of your browser to find them.
Let’s get back to the script.
1. Add a Thread Group to the Test Plan.
Test plan -> Add -> Thread (Users) -> Thread Group
Set the value ‘2’ in the Loop Count field. We will need this in the future to show a cookie passing through iterations.
2. Add the HTTP Cookie Manager element.
Thread (Users) -> Add -> Config Element -> HTTP Cookie Manager
Leave it as is for now.
3. Add an HTTP Request that opens the login page.
Thread Group -> Add -> Sampler -> HTTP Request
Fill in the following values:
- Name: Login page
- Server Name or IP: blazedemo.com
- Path: login
4. Add another HTTP Request that opens the reset password page.
Thread Group -> Add -> Sampler -> HTTP Request
Required values:
- Name: Reset password page
- Server Name or IP: blazedemo.com
- Path: password/reset
5. You are just about done! Add a listener to see your test results.
Thread Group -> Add -> Listener -> View Results Tree
You're all set! Run the script!
Check the cookie data of each request. The ‘Login page’ request on the first iteration has no cookies. All the other requests have cookie data in the request header. This means that the cookie is passing from the response to the next request, and it isn’t cleared when a new iteration starts.
Let’s play around with the Cookie Manager and try out some of its more advanced options.
Back to topThe HTTP Cookie Manager Config Element
Clear cookies on each iteration?
As the name indicates, this option allows JMeter to clear (or not clear) the cookie from iteration to iteration.
- You might clear cookies when a test user should behave like a new user on each iteration. A new user means the user would not remember any cookies from this website.
- You might not clear cookies when a test user should behave like a user who uses this website consistently a lot of times. This means the user remembers cookies from this website.
Let’s see how it works. Check the ‘Clear cookies each iteration?’ checkbox in the HTTP Cookie Manager.
Clear the results and run the script again.
Verify the ‘Login page’ request cookies for the second iteration. It has no cookies. This means that the cookie is cleared when a new iteration starts.
User-Defined Cookies (Custom Cookies)
User-Defined Cookies are another very interesting feature made possible with the HTTP Cookie Manager. Saved cookies in this section will be added to each request in the current Thread Group. This is valuable for passing information to the server. For example, you can pass the name of the Test script with custom cookies. In such a case you could distinguish JMeter script requests from the real users on the server.
To try it out, do the following:
1. Add a row to the User-Defined Cookies section of the HTTP Cookie Manager config element.
2. Fill in the following parameters:
- Name: TEST
- Value: BLAZEMETERCOOKIE
- Domain: blazedemo.com
3. Run the script and see how it works.
All requests have a cookie with the name ‘TEST’ and the value ‘BLAZEMETERCOOKIE’. Cool, isn’t it?
More possible uses for the User-Defined Cookies section:
- The ‘Save’ button stores the list of the custom cookies to a .txt file
- The ‘Delete’ button erases the selected custom cookie from the list
- The ‘Load’ button allows importing a list of custom cookies to the HTTP Cookie Manager from a .txt file
Cookie Policy
This option defines which cookie policy will be used to manage the cookies.
- standard: Compliant with the specification defined by RFC 6265, section 4. Recommended!
- standard-strict: Compliant with the well-behaved profile defined by RFC 6265, section 4. Recommended!
- ignoreCookies: All cookies are ignored. Same as delete or disable Cookie Manager.
- netscape: Corresponds to the original draft specification published by Netscape Communications.
- default: Select RFC 2965, RFC 2109 or Netscape draft compliant implementation based on cookies properties sent with the HTTP response.
- rfc2109: Compliant with the specification defined by RFC 2109.
- rfc2965: Compliant with the specification defined by RFC 2965.
- compatibility: Simulates the behavior of older versions of browsers like Mozilla FireFox and Internet Explorer.
Cookie Manager Properties
JMeter has a lot of useful properties that you can find in the jmeter.properties file. Since this post is about the Cookie Manager, let’s consider only the relevant properties. The jmeter.properties file is located in JMeter’s bin folder. You can configure these properties according to your needs directly in the file.
UPDATE: According to jmeter.properties, the following file should not be modified. This avoids having to re-apply the modifications when upgrading JMeter. Instead, only user.properties should be modified.
CookieManager.delete_null_cookies property
This property defines if cookies with null/empty values should be deleted.
Example #1
When CookieManager.delete_null_cookies=true, null/empty cookies cannot be saved in User-Defined cookies section.
When CookieManager.delete_null_cookies=false, null/empty cookies can be saved in User-Defined cookies section.
Example #2
When CookieManager.delete_null_cookies=true, null/empty cookies will not pass from the response to the next request.
When CookieManager.delete_null_cookies=false, null/empty cookies will pass from the response to the next request.
NOTE: I used a local web-application to emulate this situation, not the BlazeDemo website.
CookieManager.allow_variable_cookies property
This property defines if a variable is allowed in the User-Defined cookies section. This can be used to provide information to the server. For example, by sending a request with cookies that contain a local date/time, the server can identify the local time of the user.
Example
Set the value of the custom cookie to ‘${__time(EEE\, d MMM yyyy)}’ in the User-Defined Cookies section.
When CookieManager.allow_variable_cookies=true, the value will be interpreted as a variable.
When CookieManager.allow_variable_cookies=false, the value will be interpreted as a string.
CookieManager.save.cookies property
This property defines if cookies are stored as variables. This property can be used to get information from server cookies, to make the script more sophisticated. This also depends on the scenario, obviously. For example, let’s say the purpose of a script is to run a load test when the system has 1000 items created. Cookies from the server have information about the number of created items in the system. You can use this information from the cookies in the script, and stop the creation of items after the limit is reached.
Example
Add a parameter to the ‘Reset password page’ request.
Fill in the values:
- Name: VAR
- Value: ${COOKIE_XSRF-TOKEN}
When CookieManager.save.cookies=true, the variable VAR has the value of the XSRF-TOKEN cookie.
When CookieManager.save.cookies=false, the variable VAR has the string value ‘${COOKIE_XSRF-TOKEN}’.
CookieManager.name.prefix property
This property defines which prefix to append to the cookie name before saving it as a variable. The default value of the prefix is ‘COOKIE_’. The main purpose of the prefix is to prevent variables from conflicting with existing ones in the script. For example, if you want to save cookies that have the name USER to a variable, they would be saved to a variable with the name ${COOKIE_USER}. But if you already have that variable, they would conflict. So you can change prefix to custom (‘BLAZE_’) and the new variable will have the name ${BLAZE_USER}. The conflict is solved.
Example
Set the prefix in jmeter.properties file to ‘BLAZE_’ (CookieManager.name.prefix=BLAZE_).
Change the value of the VAR parameter in the ‘Reset password page’ request to ‘${BLAZE_XSRF-TOKEN}’.
Run the script and see the results.
The variable VAR has the value of the XSRF-TOKEN cookie. Same as it was with the ‘COOKIE_’ prefix. Don’t forget that we need CookieManager.save.cookies=true for this example.
CookieManager.check.cookies property
This property defines if received cookies are valid, before saving them to a variable. The main purpose of this property is to accept or decline invalid cookies. Cross domain cookies are an example of invalid cookies. This is when domain_1 is setting cookies for domain_2. This could happen with complex web-applications that use two domains, like Single Sign On systems, where you are logged into one website and then redirected to another. Now let’s say domain_1 is setting cookies for domain_2, and that you need those cookies to be stored in a variable for for further usage. Only the CookieManager.check.cookies property can allow us to save those cookies.
Example
A good example is a cross domain cookie. If a website (in my example localhost) is trying to set a cookie for another domain (in my example domain.com).
When CookieManager.check.cookies=true, this cookie will be ignored and the variable will not have the value.
When CookieManager.check.cookies=false, this cookie will be saved to a variable.
That’s it! This is all that can be shared about the HTTP Cookie manager for now. Thanks for reading and I hope this article was useful! Let us know what you think in the comments section below.
You can learn more JMeter for free through our BlazeMeter University.
This blog post was updated in May 2023 for accuracy.
Related Resources: