Cookies are an important part of the web. This chapter explains the purpose of cookies and how they are handled by Eggplant Performance.
What Are Cookies?
The HTTP protocol is a stateless request/response protocol whereby client requests are essentially anonymous, and each request/response pair is performed in isolation. However, servers dealing with many clients at a time often need to keep track of who they are talking to and the current state of the user's session. Cookies are often used to identify users and allow persistent data to be maintained throughout web sessions. Eggplant Performance automatically manages cookies for each virtual user when Cookie support is enabled.
The following cookies are commonly used by Eggplant Performance:
- Session Cookies: Temporary cookies that get deleted when a user exits the browser. Session cookies are known to keep track of preferences while you navigate the site, like selecting the English language version of the site.
- Persistent Cookies: Persistent cookies live outside the browser session and are often used for sites where the user returns on a regular basis. They can store information such as the user's profile or login details.
How Cookies Work
Persistent cookies are stored in files on the user's hard disk. If you know the location you can easily view a list of all the cookies stored on your computer. Windows users can usually find them by selecting Start > Control Panel > Internet Options > General > Settings > View Files.
The first time a user visits a website, the site knows nothing about them, but it anticipates that the user might visit again, and so it stores a unique persistent cookie on the user's computer. Persistent cookies are stored in files that contain a list of name/value pairs specified by the server. The next time the user visits the site, the site can identify the user by reading the information in the stored cookie.
Cookies are stored on a user's computer in response to the server sending a
Set-Cookie header. You should be able to spot these cookies using the Eggplant Performance Web Log Viewer. Any
Set-Cookie headers are displayed on the Headers and Cookies tabs in the Response section of the Request view. Below is an example
Set-Cookie header for a session cookie.
Set-Cookie: ASP.NET_SessionId=bi2jv345cwl3fpaukjwq2w55; path=/
A persistent cookie contains an
ASPNETUserSession=www.asp.net; expires=Wed, 30-Jul-2003 14:19:31 GMT; path=/
Browsers obey rules that govern the sending of cookies to sites. The rules are encoded in domain name/value pairs within a cookie. For example, the following
Set-Cookie header specifies that the cookie
user="dave" should be sent to any site in the domain
Set-Cookie: user="dave"; domain="bbc.co.uk"
Whether the user visits
news.bbc.co.uk the following header will be sent to the server:
You should be able to see these using the Eggplant Performance Web Log Viewer. Any
Set-Cookie headers are displayed on the Headers tab in the Request section of the Request view. Cookies can even be associated with parts of a website. The path name/value pair specifies a path prefix where the cookie is valid. For example,
Set-Cookie: team="Manchester City"; domain="sport.bbc.co.uk"; path="/football/"
If the user visits
sport.bbc.co.uk, only the following cookie header will be sent:
But if the user visits
sport.bbc.co.uk/football, then the following cookie headers will be sent:
Cookie: team="Manchester City"
Automatic Runtime Handling of Cookies
Runtime cookie support is enabled by the checking the Cookie Support Runtime Setting on the Web Options tab.
Acting as a First-Time Visitor
Eggplant Performance maintains a cookie cache for each web virtual user in a test run when Cookie support is enabled.
Acting as a Previous Visitor
To behave as a previous visitor to a site, you can populate the Eggplant Performance browser cookie cache with cookies that will be used at runtime using the
saveCookie("sport.bbc.co.uk/football/", "team=Manchester City");
If you want every virtual user to have a different cookie, you could use a data dictionary containing the data for each user:
// cookie from a data dictionary
When replaying a script that was recorded as a first-time visitor, the first iteration within a test run executes as a first-time visitor while subsequent iterations act as returning or previous visitors unless the API method
clearCookies() is called. See also the related method
clearCache() to clear temporary internet files from the virtual user's file cache.
Persistent and Client-Generated Cookies
The web script generator can detect persistent and client-generated cookies sent to a web server if the Web Generation Option include persistent and client generated cookies option is selected.
Persistent cookies might be detected if you have not removed cookies from your machine prior to recording a web session. Such detected cookies will be automatically inserted into a generated web script as
saveCookie() method calls.
saveCookie() method calls.
The web script generator sets the domain/path argument of
saveCookie() to the URL at which the persistent or client generated cookie was detected. Its possible that the actual domain/path argument could be higher up the path hierarchy. For example, suppose that a persistent cookie was detected when the URL
sport.bbc.co.uk/football/premiership/ was visited. This URL will become the domain argument in the generated script source. In reality, the persistent cookie might actually be valid for the domain