HTTP Cookies are used by web sites and apps to store pieces of stateful information on the user's device. A server tells the client, via a Set-Cookie HTTP header, what information it wants to be stored on the user's machine.
The user's browser will store the cookie data and associate it with the hostname of the server, and for each subsequent request to that hostname, it will include the stored cookie data in a Cookie header.
You can then control more specific rules for when cookie data should be sent or not, including limiting it to specific subdomains of the domain or a specific path. It's also possible to set an expiry date on the cookie and tell the browser only to send it over encrypted (SSL/TLS) connections.
For most intents and purposes k6 will transparently manage the receiving, storage and sending of cookies as described above, so that testing of your cookie-based web site or app will just work without you having to do anything special.
In some use cases, you might desire more control over the cookies. In k6 you have two options, either to directly manipulate HTTP headers, or use the more ergonomic cookie API. We will go through the latter below.
To simulate that a cookie has previously been set by a browser and is now supposed to be included in a subsequent request to the server we include the cookie in the cookies request parameter:
This will only apply the cookie for the request in question, but will not be sent for any subsequent requests. If you want to do that you have to add the cookie to a cookie jar, and by default there's a per-VU cookie jar we can interact with to set and inspect cookies:
The per-VU cookie jar stores all cookies received from the server in a Set-Cookie header. You can also create "local cookie jars" that overrides the per-VU cookie jar, but more on that in a bit.
You can also specify that a cookie should be overridden if already part of the per-VU cookie jar:
To see which cookies were set for a particular response we can look in the cookies property of the response object:
The response object's cookies property is a map where the key is the cookie name and the value is an array of response cookie objects (see below for description). It is an array to support multiple cookies having the same name (but different domain and/or path attributes), which is part of RFC6265.
A response cookie object contains the following properties:
|name||string||the name of the cookie|
|value||string||the value of the cookie|
|domain||string||domain deciding what hostnames this cookie should be sent to|
|path||string||limiting the cookie to only be sent if the path of the request matches this value|
|expires||string||when the cookie expires, this needs to be in the RFC1123 format looking like: Mon, 02 Jan 2006 15:04:05 MST|
|max_age||number||used for the same purpose as expires but defined as the number of seconds a cookie will be valid|
|secure||boolean||if true, the cookie will only be sent over an encrypted (SSL/TLS) connection|
To see which cookies are set, and stored in the cookie jar, for a particular URL we can use the cookieForURL() method of the cookie jar object:
The cookies object returned by the jar's cookiesForURL() method is a map where the key is the cookie name and the value is an array of cookie values (strings). It is an array to support multiple cookies having the same name (but different domain and/or path attributes), which is part of RFC6265.
To set cookies that more tightly controls the behavior of the cookie we must add the cookie to a cookie jar. An example:
Besides the per-VU cookie jar you can also create local cookie jars that can override the per-VU cookie jar on a per-request basis. An example: