Experience Manager has an internal Cookie Manager that can persist cookies received from the server and pass these cookies back to the server upon request.
Define cookie locations in cookie definitions (under the Test Administration element). Associate cookies with specific tests during deployment.
During test deployment, HTTP and HTTPS scenarios attempt to read the specified cookie file from a machine’s hard drive or a specified URL and populate the Cookie Manager.
If the loaded file contains cookies, the Cookie Manager no longer accepts or stores cookies sent from Web servers. If this file cannot be located or contains no data, it uses the default internal Cookie Manager. The cookie file can contain multiple Set-Cookie: lines.
The syntax of the Set-Cookie HTTP response header is:
Set-Cookie: NAME=VALUE; expires=DATE; path=PATH; domain=DOMAIN_NAME; secure
Table 6-1 describes the cookie formats in this HTTP response header.
Table 6-1 Cookie Format
|
NAME=VALUE |
Name of the cookie, using any characters except for a semicolon, comma, or white space. If these exceptional characters must be placed in the name or value, use an encoding method such as URL style %XX. This is the only required attribute for the Set-Cookie header. |
|
expires=DATE |
A date string that defines the valid lifetime of the cookie. After the expiration date, the cookie is no longer stored or given out.
This is an optional attribute. If it is not specified, the cookie expires when the user’s session ends.
The date string is formatted as Wdy, DD‑Mon‑YYYY HH:MM:SS GMT
This is based on RFC 822 http://ds.internic.net/rfc/rfc822.txt, RFC 850 http://ds.internic.net/rfc/rfc850.txt, RFC 1036 http://www.w3.org/hypertext/WWW/Protocols/rfc1036/rfc1036.html, and RFC 1123 http://ds1.internic.net/rfc/rfc1123.txt, with the variations that the only legal time zone is GMT and the separators between the elements of the date must be dashes. |
|
domain=DOMAIN_NAME |
When searching a list for valid cookies, a comparison occurs between the domain attributes of the cookie and the Internet domain name of the host from which the URL is fetched. If there is a tail match, the cookie goes through path matching to determine if it is sent.
Tail matching matches the domain attribute against the tail of the fully qualified domain name of the host. For example, a domain attribute of acme.com matches host names anvil.acme.com as well as shipping.crate.acme.com.
Only hosts within the specified domain can set a cookie for a domain. Domains must contain at least two or three periods to prevent domains of the form .com, .edu, and va.us.
The following seven special top-level domains require only two periods: COM, "EDU, NET, GOV, MIL, and INT. All other domains require at least three periods.
The default value of domain is the hostname of the server that generated the cookie response. |
|
path=PATH |
The path attribute specifies the subset of URLs in a domain for which the cookie is valid. For a cookie that passes domain matching, a comparison occurs between the pathname component of the URL and the path attribute. If there is a match, the cookie is valid and sent along with the URL request.
The path /foo matches /foobar and /foo/bar.html. The path “/” is the most general path.
An unspecified path is assumed to be the same path as the document described by the header that contains the cookie. |
|
secure |
Marking a cookie secure transmits it only if the communications channel with the host is secure. This means that secure cookies only travel to HTTPS (HTTP over SSL) servers.
If the secure attribute is not specified, a cookie is considered safe to send over unsecured channels. |
