A Karate scenario sets `url`, `path 'cats'`, `header Authorization = token` and `request`, then fires `method get`. Which of those four settings still apply to the next `method` step in the same scenario, and how do you make the others persist?

## One builder, reset on every call Each Karate scenario owns a single HTTP request builder. Every HTTP keyword writes into it, `method` invokes the client with it, and then the builder is **reset** — with one deliberate exception. | Field | After a call | |---|---| | `url` | **retained** | | `method` | cleared | | `path` segments | cleared | | `param` / `params` | cleared | | `header` / `headers` | cleared | | `cookie` / `cookies` | cleared | | `request` body | cleared | | `multipart` / `form field` parts | cleared | | `retry until` condition | cleared | The retention of `url` is not an accident of implementation; the reset routine opens with a comment saying the URL will be kept. It exists so that a feature focused on one resource reads naturally: ```gherkin Scenario: two calls against one resource Given url 'https://api.example.com/cats' When method get Then status 200 # url is still set; only the path had to change Given path response[0].id When method get Then status 200 ``` ## The trap: a header that quietly stops being sent The field on that table that costs teams the most time is `header`. A scenario that logs in, captures a token and then makes three more calls will send the `Authorization` header **only on the first of them** if the header was set with the `header` keyword: ```gherkin # WRONG - the header applies to exactly one call * header Authorization = 'Bearer ' + token * path 'cats' * method get * path 'dogs' * method get # <- no Authorization header at all ``` The failure is not a parse error or a warning. The second request simply goes out unauthenticated and comes back 401, which reads as a server or token problem rather than a step-ordering one. There are two correct fixes: 1. **Repeat the `header` step before each call.** Fine for one or two calls, noisy beyond that. 2. **Move it to `configure headers`.** Configured headers are merged onto the builder at invocation time, on every call, so one line in a `Background` covers the whole feature file. ```gherkin Background: * url 'https://api.example.com' * configure headers = { Authorization: 'Bearer ' + token, 'X-Tenant': tenantId } ``` `configure headers` also accepts a function, which is re-invoked per request — the usual home for a signature or a rotating token. ## Cookies are the exception that looks like an inconsistency A cookie you set yourself with `cookie name = value` is cleared with everything else. But cookies the **server** sets are handled separately: the `Set-Cookie` values on a response are recorded and automatically attached to subsequent requests in that scenario. That is why a scenario that posts to a login endpoint can immediately call a protected endpoint with no cookie step in between. The consequence worth knowing is the reverse one: that carry-forward is *sticky*. A scenario that logs in as one user and then wants to act as an anonymous caller is still sending the session cookie. Turning the auto-attach off is a config change (`configure cookies = null`), not an omission. ## How to reason about it in review When you read a scenario with more than one `method` step, split it mentally at each firing step and ask, for each block: - Which settings did this block write? Those apply to this call only. - Which settings does this call need that the block does not write? They must come from `url`, from configured headers or cookies, or from the server's own cookies — otherwise they are simply missing. That reading also explains a class of "it passes alone but fails in the suite" reports. A scenario that relied on a header set two calls earlier was never sending it; it passed only because the environment it ran against did not enforce the header. ## Why the design is this way A request builder that kept everything would make each call depend on the full history of the scenario, and a stray `param` from step three would silently leak into step nine. Resetting is the safer default, and the single retained field — the URL — is the one that is almost always constant for a resource-focused feature. Cross-cutting concerns get an explicit home in config instead of an implicit one in scenario order.