HTTP Request Samplers, Defaults, Headers, Cookies, and Cache Managers: Core Concepts and Mental Model

1. From workload schedule to protocol behavior

Chapter 04 told JMeter when virtual users should execute. Chapter 05 defines what HTTP state each user carries and what each sampler sends. A realistic workload can still be wrong if every sampler points to a hard-coded host, sessions leak across users, browser-only headers are copied blindly, or a redirect chain is counted as if it were one business operation.

2. Mental model: scoped HTTP state around one sampler

flowchart TD
W[Scenario step] --> S[HTTP Request Sampler]
D[HTTP Request Defaults] -. destination/timeouts/client .-> S
H[Header Manager] -. request headers .-> S
C[Cookie Manager] -. per-thread cookies .-> S
K[Cache Manager] -. per-thread cache .-> S
S --> HC[HttpClient4 connection]
HC --> A[Authorized local AUT]
A --> R[HTTP response]
R --> SR[SampleResult]
R -. Set-Cookie .-> C
R -. Cache headers .-> K
SR --> J[JTL / listener / jmeter.log]

The sampler is the protocol action. Defaults supply repeated fields such as scheme, host, port, implementation, and timeouts. Header Manager contributes request headers. Cookie Manager stores server-issued cookies and sends applicable cookies later. Cache Manager tracks cacheable GET resources. HttpClient4 owns client connection behavior. The target owns application/session meaning. JMeter records a SampleResult and related artifacts—it does not become the server or browser.

3. HTTP Request Sampler: the protocol action

The current HTTP Request sampler can use the Java or HttpClient4 implementation. This course explicitly selects HttpClient4 in HTTP Request Defaults so connection/keep-alive behavior is not left to an inherited property or another installation's default selection.

A sampler needs a method and path plus a resolved server/protocol/port. It can send GET, POST, PUT, PATCH, DELETE, and other supported methods depending on implementation. Connect timeout limits connection establishment wait; response timeout applies to each response wait and does not necessarily cap total elapsed time when a response arrives in chunks.

4. HTTP Request Defaults remove duplication, not intent

Defaults are inherited fields for HTTP Request samplers in scope. If twenty samplers all talk to the same local API, put http, 127.0.0.1, 8000, implementation HttpClient4, and bounded timeouts in one HTTP Request Defaults element. Each sampler then owns the path, method, and operation-specific data.

Defaults do not create requests. They also do not make a sampler's Path a prefix: current documentation says a Defaults path supplies the full default path when a sampler leaves its path blank.

5. Header Manager: explicit protocol metadata

Header Manager adds or overrides HTTP request headers. Multiple Header Managers are supported; entries are merged, and a matching header name in a later merge replaces the earlier value. That supports a broad safe default plus a narrow sampler-specific override.

Do not copy a browser's entire header set because it “looks realistic.” Send headers required by the protocol/application model: for this lab, Accept: application/json and X-Lab-Client: devops-academy-ch05. Browser fingerprinting, Sec-Fetch headers, real Authorization values, and production cookies are not appropriate defaults.

6. Cookie Manager: per-thread browser-like cookie storage

Current JMeter documentation says response cookies stored by a Cookie Manager are kept in each thread's own cookie storage area. If two virtual users each receive a different session cookie, their later requests use their own stored cookie. This is the normal pattern for session simulation.

“Clear Cookies each Iteration” clears server-defined cookies on Thread Group loop boundaries while manually defined GUI cookies remain. Decide whether one JMeter thread represents the same user across loops before choosing that option.

7. Cache Manager: per-thread HTTP cache simulation

HTTP Cache Manager maintains a separate cache for each virtual-user thread. With Cache-Control/Expires processing enabled, a fresh GET can populate the cache. If a later GET is still fresh, JMeter may return the cached result without contacting the server. With stale validators, a conditional GET can produce a 304 response.

This is protocol/cache simulation, not full browser cache behavior. There is no DOM, service worker, rendering pipeline, or browser memory cache outside what JMeter's HTTP Cache Manager implements.

8. Redirect Automatically versus Follow Redirects

A redirect chain can increase the parent sample's elapsed time even when the final application handler is fast. Do not call the entire parent elapsed “final-page server latency.”

9. Keep-alive and connection reuse

With HttpClient4, selecting Use KeepAlive allows the client to reuse persistent HTTP connections when protocol/server conditions permit. The server fixture records client ports so a learner can observe whether sequential requests appear to reuse a connection.

Do not convert one observed reused socket into a universal guarantee. Connection pools, server close behavior, timeouts, DNS, proxies, SSL contexts, thread boundaries, and target configuration all affect connection lifecycle.

10. Embedded resources are HTTP requests, not JavaScript execution

If Retrieve All Embedded Resources is enabled for an HTML response, JMeter parses supported HTML/CSS references and can fetch images, stylesheets, external scripts, frames, and other referenced resources. Optional concurrent retrieval changes the request pattern further.

Fetching /asset.js does not execute the JavaScript. The local fixture's script would change DOM text in a real browser, but JMeter never runs that DOM code. Use Selenium or a real browser when rendered behavior, JavaScript execution, layout, Web APIs, or browser timing is the performance question.

11. Inspect HTTP state before changing it

• Record sampler method/path and resolved Defaults scope.
• List Header Managers and overlapping header names.
• Identify Cookie Manager scope and whether cookies are server-issued or manually configured.
• Identify Cache Manager options and whether cached GETs can skip target calls.
• Record redirect and embedded-resource options.
• Record implementation, keep-alive, timeouts, JMeter/Java versions, target allow-list, and JTL schema.
• Use a one-thread View Results Tree only for bounded request/response debugging; use CLI JTL + jmeter.log for load evidence.

Knowledge check

Official references and version notes

• Component Reference — current HTTP Request, HTTP Request Defaults, HTTP Header Manager, HTTP Cookie Manager, HTTP Cache Manager, redirect, keep-alive, and embedded-resource semantics.
• Elements of a Test Plan — scope and execution architecture around samplers and configuration elements.
• Properties Reference — current CSV/JTL save fields and defaults such as response/request header retention and connect time.
• Functions and Variables — thread-local runtime values and function boundaries.
• Getting Started — GUI authoring/debugging versus CLI load execution.
• Best Practices — lean load generation and result/listener guidance.
• Apache JMeter downloads — current production release and release-specific Java requirement.