Skip to content

JavaScript Cookies

Problem: Some applications set cookies using JavaScript instead of standard HTTP Set-Cookie headers. During recording, Load Tester captures the JavaScript code, but virtual users don't run JavaScript; they replay HTTP transactions. If the cookie value is required for subsequent requests, replay fails with authentication or session errors.

When You Need This

You'll know JavaScript cookies are the problem if:

  • Recording succeeds, but replay fails with 401/403 errors or session errors
  • Inspecting recorded transactions shows JavaScript setting a cookie: document.cookie = "session=abc123"
  • HTTP headers during recording don't show a Set-Cookie header for the required cookie
  • The application depends on client-side JavaScript to generate or modify cookie values

Common scenarios:

  • Single-page applications (SPAs) that manage session state in JavaScript
  • Analytics/tracking cookies set by JavaScript tag managers
  • Security tokens generated client-side and stored in cookies
  • Browser fingerprinting cookies set via JavaScript

Why Load Tester Doesn't Run JavaScript

Performance constraint: Virtual users must be lightweight. Running a full JavaScript engine (Chrome's V8) for every virtual user would consume massive CPU and memory, limiting scalability to perhaps 10-50 users per machine instead of 500-1000+.

HTTP-level simulation: Load Tester replays the HTTP transactions your browser sent, not the browser itself. This works because web servers only see HTTP requests; they don't know (or care) whether those requests came from a real browser or a load testing tool. JavaScript runs in the browser to generate HTTP requests, but once recorded, you can replay the HTTP without re-executing the JavaScript.

The trade-off: This design maximizes scalability but requires manual configuration when JavaScript performs actions that affect HTTP headers, like setting cookies.

The workflow has three steps:

  1. Locate the cookie value in an HTTP response (it's usually embedded somewhere, even if JavaScript extracts it)
  2. Configure an extractor to capture the value from the response
  3. Configure a processor to set the cookie before the next request that needs it

The cookie value usually appears somewhere in an HTTP response, even if JavaScript extracts it. Check these locations:

Where to look (in order of likelihood):

  1. Hidden form fields: <input type="hidden" name="token" value="abc123">
  2. JavaScript variable assignments: var sessionToken = "abc123";
  3. JSON responses: {"session": "abc123", "expires": 3600}
  4. Embedded in HTML comments: <!-- session:abc123 -->
  5. URL query parameters: Redirect to /dashboard?session=abc123

How to find it:

  1. Run a replay and let it fail (to generate Headers View data)
  2. Open Headers View for the failing transaction
  3. Click "View Request Headers" to see what cookie Load Tester tried to send
  4. Note the cookie name (e.g., sessionToken) and the value that's missing or wrong
  5. Search backward through previous responses in Headers View for that value
  6. When you find it, note the surrounding text (you'll use this for the extractor)

Example: If the cookie is sessionToken=abc123, search for abc123 in previous responses. You might find:

<script>
  var sessionToken = "abc123";
  document.cookie = "sessionToken=" + sessionToken + "; path=/";
</script>

The value abc123 is right there in the HTML; you just need to extract it.

Step 2: Configure an Extractor

Extractors capture values from HTTP responses and store them in variables for later use. You'll create a boundary extractor (easiest) or regex extractor (more flexible) depending on the surrounding text.

To configure an extractor:

  1. Open Actors View: Navigate to the transaction where the cookie value appears
  2. Select the Extractors tab (bottom panel)
  3. Click "Add Extractor" (toolbar button)
  4. Configure the extractor:
Field Value Purpose
Name Descriptive name (e.g., sessionToken) You'll reference this name in the processor
Type Boundary or Regex Boundary is easier; Regex handles complex patterns
Start Boundary Text before the value (e.g., var sessionToken = ") Extractor finds this text first
End Boundary Text after the value (e.g., ";) Extractor stops capturing here
Variable Name sessionToken Name to store the extracted value

Example boundary extractor for var sessionToken = "abc123";:

  • Start Boundary: var sessionToken = "
  • End Boundary: ";
  • Variable Name: sessionToken

Example regex extractor for <input type="hidden" name="csrf" value="xyz789">:

  • Regex Pattern: name="csrf"\s+value="([^"]+)"
  • Capture Group: 1 (the value inside parentheses)

  • Variable Name: csrfToken

  • Click OK to save the extractor

  • Run a replay to verify the extractor captures the value (check Replay View → Variables)

Processors modify HTTP requests before they're sent. You'll create a cookie processor that sets the cookie value using the variable captured by the extractor.

To configure a processor:

  1. Open Actors View: Navigate to the transaction that sends the cookie (usually the next transaction after the extractor)
  2. Select the Processors tab (bottom panel)
  3. Click "Add Processor" (toolbar button)
  4. Select "Cookie Processor"
  5. Configure the processor:
Field Value Purpose
Cookie Name Name the server expects (e.g., sessionToken) Must match what the application expects
Cookie Value ${sessionToken} References the variable from the extractor
Domain Usually leave blank (auto-detected) Specifies which domain receives the cookie
Path Usually / (applies to all URLs) Restricts cookie to specific paths

Example processor to set sessionToken cookie:

  • Cookie Name: sessionToken
  • Cookie Value: ${sessionToken} (uses the variable from the extractor)
  • Domain: (leave blank)

  • Path: /

  • Click OK to save the processor

  • Run a replay to verify:
  • Transaction succeeds (green in Replay View)
  • Headers View shows the cookie in the request headers
  • No 401/403/session errors

Scenario: Application sets a session token via JavaScript: document.cookie = "session=" + token;

Step 1: Locate the value in the response:

<script>
  var token = "abc123def456";
  document.cookie = "session=" + token + "; path=/; secure";
</script>

Step 2: Configure extractor (Actors View → Extractors tab):

  • Name: Session Token Extractor
  • Type: Boundary
  • Start Boundary: var token = "
  • End Boundary: ";
  • Variable Name: sessionToken

Step 3: Configure processor (Actors View → Processors tab, on the NEXT transaction):

  • Type: Cookie Processor
  • Cookie Name: session
  • Cookie Value: ${sessionToken}
  • Path: /

Result: Extractor captures abc123def456 from the response, processor sets Cookie: session=abc123def456 on subsequent requests.

Extractor Captures Wrong Value

Symptom: Variable contains unexpected text or nothing at all.

Likely causes:

  1. Boundaries are too broad and capture extra text
  2. Boundaries don't account for whitespace (spaces, tabs, newlines)
  3. Response format changed between recording and replay

Solution:

  • Add more specific boundaries: Include more surrounding text to narrow the match
  • Use Regex instead of Boundary: Regex handles whitespace and variations better
  • View the actual response in Headers View to verify the expected text exists

Symptom: Headers View shows the cookie in the request, but the server rejects it (401/403 error).

Likely causes:

  1. Cookie domain/path is wrong and the browser (or Load Tester) doesn't send it
  2. Cookie requires Secure flag but replay isn't using HTTPS
  3. Cookie requires HttpOnly flag but processor doesn't set it
  4. Cookie value is encoded (URL-encoded, Base64) and processor sends the raw value

Solution:

  • Check domain/path: Leave domain blank (auto-detect) and use path / unless you know the exact requirements
  • Verify HTTPS: If the application requires Secure cookies, ensure your test case uses https:// URLs
  • Add encoding: If the value needs URL encoding, use a Variable Modifier processor first
  • Inspect Headers View: Compare the cookie Load Tester sends vs. what the browser sent during recording

Extractor Captures Wrong Value or Nothing

Symptom: Extractor variable contains unexpected text, partial text, or is empty.

Likely causes:

  1. Boundaries too broad (capture too much text)
  2. Boundaries too narrow (never match)
  3. Response format changed between recording and replay
  4. Whitespace in boundaries (spaces, tabs, newlines) not accounted for

Solution:

  • View the actual response in Headers View to verify the expected text exists
  • Use more specific boundaries: Include more surrounding text to narrow the match
  • Switch to Regex extractor: Regex handles whitespace variations better
  • Enable extractor logging: Check diagnostic logs to see what the extractor matched

Ask the AI to Configure JavaScript Cookie Extraction

If you're struggling to locate the cookie value or configure extractors/processors:

My replay fails with session errors. I think the application sets a cookie
via JavaScript. Can you help me find where the cookie value appears in the
response and configure an extractor and processor to handle it?

The AI can:

  • Search Headers View to locate the cookie value in HTTP responses
  • Identify the best extraction strategy (boundary vs. regex)
  • Generate extractor configuration with appropriate boundaries
  • Configure the processor to set the cookie on the correct transaction
  • Verify the configuration by analyzing replay results
  • Troubleshoot extractor/processor issues