HTTP Cookies are used by web sites and apps to store pieces of stateful information on user devices. Through the Set-Cookie HTTP header, a server tells a client what information it wants stored on the user machine.
The user's browser stores the cookie data and associates it with the hostname of the server. For each subsequent request to that hostname, it includes the stored cookie data in a Cookie header.
You can then control more specific rules for whether to send the cookie data or not, including limiting it to specific subdomains or paths. You can also to set an expiry date on the cookie and tell the browser to send it only over encrypted (SSL/TLS) connections.
For most purposes, k6 transparently manages the reception, storage, and transmission of cookies as described. Testing of your cookie-based web site or app will just work without requiring any special action of you.
In some cases, though, you might want more control over cookies. k6 provides multiple options to do this. You can:
- Directly manipulate HTTP headers,
- Use the more ergonomic cookie API.
The following section shows how to use the Cookie API.
To simulate that a cookie has previously been set by a browser and is now supposed to be included in subsequent requests to the server, include the cookie in the cookies request parameter:
This applies only to the cookie for the request in question. It isn't sent for any subsequent requests. To send the cookie for subsequent requests, add it to a cookie jar. By default, k6 has a cookie jar for each VU, which you 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 override the per-VU cookie jar (shown in a subsequent section).
You can also override a cookie that is already part of the per-VU cookie jar:
To see which cookies were set for a particular response, 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. This array can support multiple cookies that have the same name but different domain or path attributes, as specified in 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, 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 to override the per-VU cookie jar on a per-request basis: