Which JMeter property stops the HTTP Authorization Manager from sending BASIC credentials unchallenged?

## What the Authorization Manager is doing The **HTTP Authorization Manager** holds a table of `Base URL`, `Username`, `Password`, `Domain`, `Realm` and `Mechanism` rows. Before a sampler runs, JMeter looks the request URL up in that table. The match is a plain prefix test against the entry's Base URL, evaluated **in table order**, and the first hit wins — there is no longest-match logic, so the most specific URLs must be listed first. Duplicate URLs are ignored. The `Mechanism` column offers `BASIC`, `DIGEST` and `KERBEROS` (plus a deprecated `BASIC_DIGEST` alias). The Java sampler implementation supports only `BASIC`; HttpClient4 supports all three. There is no Bearer mechanism — an OAuth or JWT token belongs in an **HTTP Header Manager** as a literal `Authorization` header, not here. ## What preemptive means here With `httpclient4.auth.preemptive=true` — the documented default, and the behaviour since 3.2 — JMeter adds a request interceptor that runs first on every request. It finds the matching authorization entry, seeds an auth cache with a BASIC scheme for that host, and the `Authorization` header therefore goes out on the **first** request, unprompted. Set the property `false` and that interceptor is not registered. JMeter supplies a managed credentials provider instead, and the flow becomes the classic one: 1. the request goes out with no `Authorization` header; 2. the server answers with a challenge; 3. HttpClient answers the challenge and replays the request. All three steps happen inside a single sampler execution, so you get one sample row whose elapsed time now includes the extra leg — not two rows. ## Why anyone would turn it off - To exercise the challenge path itself, because that is what a real browser does on first contact and you want the server's 401 handling under load. - To avoid leaking credentials to endpoints that never asked for them, when one Base URL prefix is broader than intended. - To reproduce a defect that only appears when the client waits to be asked. And why you would leave it on: it removes a round trip per protected request, and the header is visible in the Tree View Listener's request tab, which makes the plan far easier to debug. ## Neighbouring switches people confuse with it | Setting | What it really controls | |---|---| | `httpclient4.auth.preemptive` | Whether BASIC credentials are sent before a challenge, on the HttpClient sampler | | `Clear auth on each iteration` | Clears cached **Kerberos** subjects at the iteration boundary; it is not about BASIC | | `kerberos.spnego.strip_port` | Whether the port is dropped when building the Kerberos SPN | | `kerberos.spnego.delegate_cred` | Whether credentials are delegated to web servers under SPNEGO; off by default | A further wrinkle from the manual: the Java implementation does preemptive authentication too, but it does not hand the `Authorization` header back when JMeter fetches request headers, so the header can be missing from the listener even though it was sent. On HttpClient4 the header is shown. ## Where to set it Put the line in `bin/user.properties`, or pass `-Jhttpclient4.auth.preemptive=false` on the command line. It is read into a static field when the HttpClient4 implementation class loads, so changing it from a script mid-run does nothing. Passwords, incidentally, are stored unencrypted in the `.jmx` — use variables fed from a config element rather than typing them into the table.