Per-Request Behaviour

## The answer, then the mechanism The run uses the **request's** value. A `protocolProfileBehavior` member declared closer to the request beats the same member declared further away, and the collection root is the furthest away of all. This is the question interviewers actually ask about this field, because a collection is a tree and every level of it may declare the same switch. The useful answer names the rule (**nearest wins**), the resolver that implements it, and the two edges: merging is per member, and an undeclared member still has a value. ## The resolver The SDK exposes the effective value through `Item#getProtocolProfileBehaviorResolved`. What it does: 1. Starts from the item being sent. 2. Walks its ancestors with `forEachParent({withRoot: true})` — every enclosing folder, and the collection root itself, which is what `withRoot` includes. 3. Merges the blocks it finds so that a value declared nearer the item overrides the same member declared further up. 4. Returns one merged object, which is the entry's effective behaviour block. Notice that the request's own stored block is not the answer on its own, and neither is the root's. Only the resolver's output describes what will actually happen. ## Merge, not replace The single most common misconception is that a request-level block **replaces** the inherited one. It does not; the merge is member by member. Take a root that declares two members and a request that declares one: ```json { "protocolProfileBehavior": { "followRedirects": false, "strictSSL": true }, "item": [ { "name": "alias", "protocolProfileBehavior": { "followRedirects": true }, "request": { "method": "GET", "url": "https://example.test/alias" } } ] } ``` The effective block for `alias` is `followRedirects: true` **and** `strictSSL: true`. The request overrode exactly the member it named and inherited the other. - A member declared only at the root applies everywhere below it. - A member declared on a folder applies to that subtree, at any depth. - A member declared on the request applies to that one entry. - A member declared at two levels resolves to the nearer one. ## Then the runtime's defaults Inheritance is only the first half. The merged block is handed to the runtime, which resolves it through `resolveWithProtocolProfileBehavior()` against `defaultOpts`. So a member that nobody declared anywhere in the tree is not missing at send time — it takes the runtime's own value. That is why *nothing declared it* and *it is off* are different statements, and why a candidate who says a member is simply absent has answered half the question. | Where a member is declared | Effective value | |---|---| | Request only | the request's | | Folder only | the folder's, for the whole subtree | | Root only | the root's, everywhere below | | Root and request | the request's — nearest wins | | Folder and a nested folder | the nested folder's | | Nowhere | the runtime's default from `defaultOpts` | ## Why this matters in practice - **Diagnosis.** When one entry in a shared collection behaves unlike its neighbours, the difference is often a block on that entry or on a folder above it, and you find it by asking which level supplied each member. - **Review.** A root-level house rule with a small number of deliberate, visible exceptions is far easier to reason about than the same switches scattered across dozens of entries. - **Prediction.** Because the merge is per member, adding one member to a request is a narrow change; it does not silently discard the rest of what that request inherited. ## Where the answer stops The rule settles **which declaration of a switch is in force** and nothing beyond it. What a client re-sends when it does follow a redirect, whether a credential survives a cross-origin hop, how a redirect loop is stopped and which status code rewrites the method belong to the HTTP redirect and status-code topics. Certificate verification as a discipline belongs to application security, cookie attribute meanings to HTTP cookies, and the shared cookie store, the proxy list and certificate selection to the neighbouring transport topics. Answer the inheritance question; cede the protocol question explicitly, because doing so is itself a sign of a candidate who knows where the boundary is. ## Mistakes to avoid - Saying the collection root wins because it is the broader scope. - Saying a request-level block replaces everything inherited. - Forgetting that the root participates at all, and stopping at the nearest folder. - Treating an undeclared member as unset rather than as the runtime's default.