skip to content

What do JMeter samplers inherit from an HTTP Request Defaults element, and what wins?

level: middleimportance: should knowfreq 58%

answer

  1. It fills blanks, it never overrules
  2. Nearest element in the tree wins
  3. Path is a default, not a prefix
  4. Unticked boxes store nothing at all

basics

~10 s

Only the fields a sampler leaves empty. HTTP Request Defaults supplies server, port, protocol, timeouts, implementation, proxy and the embedded-resource settings, and a value already present on the sampler always wins.

solid answer

~50 s

JMeter collects the config elements in scope for a sampler when it compiles the test tree, then merges them into the sampler before every execution of it (undoing the merge afterwards); the merge installs a value only where the sampler has no property of that name or holds an empty string. So an HTTP Request Defaults element fills blanks and never overrides. Collection runs from the sampler outwards, which means the **nearest** HTTP Request Defaults fills a field first and an outer one then finds it taken — nesting a second Defaults inside a controller is a real override. Two documented gotchas: **Path** on the Defaults is a default for the whole path, not a prefix to the sampler's path; and because the redirect checkboxes store nothing when unticked, a Defaults element can switch **Follow Redirects** on for samplers that have it off but can never switch it off.

code

xml · 8 lines
xml
<ConfigTestElement guiclass="HttpDefaultsGui" testclass="ConfigTestElement" testname="HTTP Request Defaults">
  <stringProp name="HTTPSampler.protocol">https</stringProp>
  <stringProp name="HTTPSampler.domain">shop.example.invalid</stringProp>
  <stringProp name="HTTPSampler.port">443</stringProp>
  <stringProp name="HTTPSampler.connect_timeout">2000</stringProp>
  <stringProp name="HTTPSampler.response_timeout">10000</stringProp>
  <stringProp name="HTTPSampler.implementation">HttpClient4</stringProp>
</ConfigTestElement>

go deeper

for a junior

Know why the element exists and how to use it: fill the shared fields there once and leave the same fields empty on every sampler.

for a middle

State the merge rule in one sentence — blanks are filled, existing values are kept — and be ready with the Path-is-not-a-prefix correction.

for a senior

Reason about a plan you inherited: work out which Defaults element in scope actually supplied a value, and spot the redirect flag that a Defaults element turned on behind the sampler's back.

for a principal

Set the convention for the team: which fields belong on a Defaults element, how many are allowed in one plan, and how nested overrides are reviewed so a change at the top cannot silently redirect a whole suite.

An **HTTP Request Defaults** element exists so twenty-five samplers pointed at the same host do not carry the same host twenty-five times. It is a config element, and what it does is narrower than "sets defaults" suggests. ## The merge rule, exactly When JMeter compiles the test tree it collects the config elements in scope for a sampler; the merge itself happens before every execution of that sampler, and is undone once the sample is done. The merge walks the config element's properties and, for each, looks at the sampler: - if the sampler has **no property of that name**, or holds an **empty string** there, the config element's value is installed; - otherwise the existing value is kept and the incoming one is discarded. Two consequences follow directly. First, **the sampler always wins** — an HTTP Request Defaults element can never override a field you filled in. Second, the collection walks the tree from the sampler outwards, so when two HTTP Request Defaults elements are in scope, the **nearer** one fills a field first and the outer one finds it already occupied. Nesting a second Defaults inside a Simple Controller is therefore a legitimate way to override a broader one. ## What is worth putting on it The element carries most of the sampler's connection-shaped fields: - **Server Name or IP**, **Port Number**, **Protocol** and **Content encoding**; - **Connect** and **Response** timeouts, in milliseconds; - **Implementation** — the dropdown offers `HttpClient4` and `Java`; leaving it blank falls back to the JMeter property `jmeter.httpsampler`, whose built-in default is `HttpClient4`; - proxy host, port, username and password; - **Retrieve All Embedded Resources**, the **Parallel downloads** number, and the **URLs must match** / **URLs must not match** regexes; - **Path** and a parameter table. ## Where it surprises people **Path is not a prefix.** The manual is explicit: the Path on an HTTP Request Defaults is a default for the *whole* path, not something prepended to the sampler's own path. A sampler that already has `/api/orders` ignores the Defaults path entirely; a sampler with an empty path gets the Defaults path verbatim. If you want a base path in front of everything, that is a variable in the Path field, not this element. **Port is not special-cased.** All port values are treated alike: a sampler that specifies no port takes the Defaults port if one is given. **An unticked checkbox is not the same as "off".** The **Follow Redirects** and **Redirect Automatically** checkboxes only write a property when they are *ticked*; unticking one removes the property from the element rather than storing `false`. Because the merge fills absent properties, a Defaults element with Follow Redirects on will switch it on for every sampler that has it off — and a sampler that has it on cannot be switched off from the Defaults. The manual states the asymmetry as a limitation of two-state buttons, and it is exactly why some plans behave differently from what the sampler's own screen shows. ## A layout that works 1. One HTTP Request Defaults directly under the Test Plan carrying protocol, server, port and both timeouts. 2. Samplers that leave those four fields empty and set only method, path and parameters. 3. Where one section of the plan talks to a different host, a second Defaults inside that controller, which wins because it is nearer. ## Reading a plan you did not write If a sampler's screen shows an empty Server field and the run still reaches a host, the value is coming from a Defaults element somewhere above it — and the innermost one in scope is the one that supplied it. Conversely, if a sampler's Server field is filled in, no Defaults element anywhere can be responsible for where that request went.

  • Two HTTP Request Defaults elements are in scope for one sampler and both set Server. Which applies?
    The nearer one. JMeter collects config elements walking outwards from the sampler, so the innermost element is merged first and installs the value; the outer element is merged afterwards, finds the property already present, and its value is discarded.
  • If the Implementation field is blank on both the sampler and the Defaults, what does JMeter use?
    It falls back to the JMeter property `jmeter.httpsampler`, whose built-in default is `HttpClient4`. The dropdown itself only ever offers `HttpClient4` and `Java`; an old plan saved with `HttpClient3.1` is mapped onto the HttpClient4 implementation.

saying these in an interview costs you the question

  • Says the Defaults element overrides values set on the sampler
  • Treats the Defaults Path as a prefix for sampler paths
  • Thinks an outer Defaults element beats a nearer one
  • Believes unticking a box on the sampler blocks inheritance
  • Assumes it only carries server and port