In a saved Postman collection file, what is the protocolProfileBehavior block and which entries may carry one?

juniorshould knowfreq 34%

answer

A per-entry block in the saved file
Switches read before the call is made
Collection root, folder, or the request
Runtime PPB_OPTS names the members
Nearest declaration wins the merge

basics

~10 s

protocolProfileBehavior is a collection-format field holding per-entry sending switches such as strictSSL, disableCookies and followRedirects. The collection root, a folder and an individual request may each declare one, and the nearest declaration wins.

solid answer

~40 s

protocolProfileBehavior is a field of the Postman collection format: a small object of switches the sending program reads before it makes a call. The runtime's PPB_OPTS list names the members it understands — strictSSL, disableCookies, followRedirects, maxRedirects, followOriginalHttpMethod, followAuthorizationHeader, removeRefererHeaderOnRedirect, insecureHTTPParser and protocolVersion. It is not a script, a credential or a variable set; it only changes how the call is dispatched. It may sit on the collection root, on a folder, and on the request itself, because the SDK's Item#getProtocolProfileBehaviorResolved walks every parent with forEachParent({withRoot: true}) and merges what it finds, the nearest declaration winning. What a switch means on the wire belongs to the HTTP and TLS topics, not to this block.

`protocolProfileBehavior` is a field of the **Postman collection format**: a small object of switches the sending program reads before it makes a call. The runtime's `PPB_OPTS` list names the members it understands — `strictSSL`, `disableCookies`, `followRedirects`, `maxRedirects`, `followOriginalHttpMethod`, `followAuthorizationHeader`, `removeRefererHeaderOnRedirect`, `insecureHTTPParser` and `protocolVersion`. It is not a script, a credential or a variable set; it only changes how the call is dispatched. It may sit on the collection root, on a folder, and on the request itself, because the SDK's `Item#getProtocolProfileBehaviorResolved` walks every parent with `forEachParent({withRoot: true})` and merges what it finds, the nearest declaration winning. What a switch means on the wire belongs to the HTTP and TLS topics, not to this block.

code

json · 11 lines

json

{
  "info": { "name": "orders" },
  "protocolProfileBehavior": { "followRedirects": false },
  "item": [
    {
      "name": "legacy alias",
      "protocolProfileBehavior": { "followRedirects": true },
      "request": { "method": "GET", "url": "https://example.test/alias" }
    }
  ]
}

go deeper

for a junior

Be ready to say what the block is in one line: per-entry sending switches saved in the collection file, not code and not data. Recall two or three member names and that a request, a folder or the root may declare it.

for a middle

Be ready to explain the mechanics: the format declares the field, the runtime's PPB_OPTS gives it meaning, and the SDK resolver merges ancestors down with the nearest declaration winning per member rather than replacing the block.

for a senior

Be ready to use it in diagnosis. When one request in a shared collection behaves unlike its siblings, know to look for a block on it or on a folder above it, and to say which level supplied each effective member.

for a principal

Be ready to set policy on it. Decide whether switches belong at the root as a house rule with narrow exceptions, or per request, and weigh how reviewable a scattered set of per-entry overrides stays as a collection grows.

What the block is

protocolProfileBehavior is a field of the Postman collection format — one of the keys a saved collection file may carry, alongside info, item, event, auth and variable. Its value is an object of switches the sending program reads before it makes the call: whether this entry follows a redirect at all, whether it touches the run's shared cookie store, how strictly a certificate is checked, which protocol generation is spoken. The block holds no logic and no data. It changes how a call is dispatched, never what is sent.

Attribution matters here, because two different projects are involved:

the format owns the field name, so a collection file declares protocolProfileBehavior;
the runtime owns the members, so what a declared key actually does is decided when the entry is executed.

Which entries may carry one

A collection is a recursive tree: the root holds an item array, an entry in that array is a folder when it holds its own item list, and a leaf entry is a request. A protocolProfileBehavior block may be declared at any of those levels:

on the collection root, as a house rule for everything below it;
on a folder, at any depth, covering the subtree under it;
on a single request item, as an exception for one call.

That is why the SDK exposes a resolver rather than a plain getter: the value that governs a send is not necessarily the one written on the request.

Which members the runtime understands

The runtime's PPB_OPTS is the list of members that mean anything. Grouped by what they touch:

Member in `PPB_OPTS`	What it switches for this entry
`strictSSL`	how strictly the certificate is checked
`disableCookies`	whether the call touches the run's shared cookie store
`followRedirects`, `maxRedirects`, `followOriginalHttpMethod`, `followAuthorizationHeader`, `removeRefererHeaderOnRedirect`	the redirect family — the behaviour each toggles is HTTP's, not the file's
`insecureHTTPParser`, `protocolVersion`	how the message itself is parsed and which generation is spoken

Note what is not in that list, because candidates routinely try to put it there: no credentials, no variable values, no script bodies, no proxy list, no certificate files. Those are separate fields of the format with their own resolution rules.

How the effective value is chosen

The SDK's Item#getProtocolProfileBehaviorResolved is asked for the item's effective block.
It walks the item's ancestors with forEachParent({withRoot: true}), so folders and the collection root are included.
The blocks are merged member by member; where the same member is declared more than once, the nearest declaration to the request wins.
The runtime then resolves that merged object through resolveWithProtocolProfileBehavior() against its own defaultOpts, so a member nobody declared still has a value.

Merging is per member, not wholesale replacement. A request that declares only disableCookies keeps every other member it inherited; it overrides exactly the one key it names.

What this block does not settle

This is the boundary that keeps answers honest. The block says which switch a saved entry carries and which declaration of it wins — nothing else:

what a client re-sends after a redirect, whether a credential survives a hop, and how a loop is stopped belong to HTTP redirect handling;
which status code preserves the original method belongs to HTTP status codes;
what two sides agree during a handshake, and why relaxing validation is a bad idea, belong to TLS and application security;
what a cookie attribute means belongs to HTTP cookies;
the shared cookie store itself and the operations that read and write it, the proxy list and its bypass test, and choosing a certificate by matching the target URL each belong to the other transport topics. This block keeps only the member that switches the cookie store off.

Mistakes reviewers see

Calling the block a pre-request script, or expecting it to run code.
Assuming only the collection root may declare it, then being surprised that one request behaves differently.
Assuming a request-level block replaces the whole inherited block instead of merging into it.
Reading the format's schema and concluding the member names are defined there — they are not.
Putting a token or a hostname in it because it looks like a convenient per-request settings bag.

## What the block is `protocolProfileBehavior` is a **field of the Postman collection format** — one of the keys a saved collection file may carry, alongside `info`, `item`, `event`, `auth` and `variable`. Its value is an object of **switches the sending program reads before it makes the call**: whether this entry follows a redirect at all, whether it touches the run's shared cookie store, how strictly a certificate is checked, which protocol generation is spoken. The block holds no logic and no data. It changes *how* a call is dispatched, never *what* is sent. Attribution matters here, because two different projects are involved: - the **format** owns the field name, so a collection file *declares* `protocolProfileBehavior`; - the **runtime** owns the members, so what a declared key actually does is decided when the entry is executed. ## Which entries may carry one A collection is a recursive tree: the root holds an `item` array, an entry in that array is a folder when it holds its own `item` list, and a leaf entry is a request. A `protocolProfileBehavior` block may be declared at any of those levels: - on the **collection root**, as a house rule for everything below it; - on a **folder**, at any depth, covering the subtree under it; - on a single **request item**, as an exception for one call. That is why the SDK exposes a resolver rather than a plain getter: the value that governs a send is not necessarily the one written on the request. ## Which members the runtime understands The runtime's `PPB_OPTS` is the list of members that mean anything. Grouped by what they touch: | Member in `PPB_OPTS` | What it switches for this entry | |---|---| | `strictSSL` | how strictly the certificate is checked | | `disableCookies` | whether the call touches the run's shared cookie store | | `followRedirects`, `maxRedirects`, `followOriginalHttpMethod`, `followAuthorizationHeader`, `removeRefererHeaderOnRedirect` | the redirect family — the behaviour each toggles is HTTP's, not the file's | | `insecureHTTPParser`, `protocolVersion` | how the message itself is parsed and which generation is spoken | Note what is **not** in that list, because candidates routinely try to put it there: no credentials, no variable values, no script bodies, no proxy list, no certificate files. Those are separate fields of the format with their own resolution rules. ## How the effective value is chosen 1. The SDK's `Item#getProtocolProfileBehaviorResolved` is asked for the item's effective block. 2. It walks the item's ancestors with `forEachParent({withRoot: true})`, so folders **and** the collection root are included. 3. The blocks are merged member by member; where the same member is declared more than once, the **nearest declaration to the request wins**. 4. The runtime then resolves that merged object through `resolveWithProtocolProfileBehavior()` against its own `defaultOpts`, so a member nobody declared still has a value. Merging is per member, not wholesale replacement. A request that declares only `disableCookies` keeps every other member it inherited; it overrides exactly the one key it names. ## What this block does not settle This is the boundary that keeps answers honest. The block says **which switch a saved entry carries and which declaration of it wins** — nothing else: - what a client re-sends after a redirect, whether a credential survives a hop, and how a loop is stopped belong to HTTP redirect handling; - which status code preserves the original method belongs to HTTP status codes; - what two sides agree during a handshake, and why relaxing validation is a bad idea, belong to TLS and application security; - what a cookie attribute means belongs to HTTP cookies; - the shared cookie store itself and the operations that read and write it, the proxy list and its bypass test, and choosing a certificate by matching the target URL each belong to the other transport topics. This block keeps only the member that switches the cookie store off. ## Mistakes reviewers see - Calling the block a pre-request script, or expecting it to run code. - Assuming only the collection root may declare it, then being surprised that one request behaves differently. - Assuming a request-level block replaces the whole inherited block instead of merging into it. - Reading the format's schema and concluding the member names are defined there — they are not. - Putting a token or a hostname in it because it looks like a convenient per-request settings bag.

Does a block declared on a folder reach requests inside a nested folder below it?
Yes. The SDK resolver walks every ancestor of the item, so a block on an outer folder reaches requests nested at any depth beneath it. A nearer folder or the request itself overrides only the members it names, because the merge is per member rather than wholesale.
If a request declares only disableCookies, does it lose the switches it inherited?
No. Members the request does not name keep the value from the nearest ancestor that declares them, and members nobody declares anywhere fall through to the runtime's own values in `defaultOpts`. Declaring one member is an override of that member alone.

It is a handling note stuck to one envelope rather than the letter inside it: the note nearest the envelope is the one the post room reads.

saying these in an interview costs you the question

Calling protocolProfileBehavior a pre-request script or event
Claiming only the collection root may declare the block
Saying the format's schema lists the legal member names
Believing a request block replaces the whole inherited block
Using the block to store tokens, hosts or variables

In a saved Postman collection file, what is the protocolProfileBehavior block and which entries may carry one?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

What the block is

Which entries may carry one

Which members the runtime understands

How the effective value is chosen

What this block does not settle

Mistakes reviewers see

▾common follow-ups2 questions

▾analogy~10 s

▾red flags5 flags

What the block is

Which entries may carry one

Which members the runtime understands

How the effective value is chosen

What this block does not settle

Mistakes reviewers see

answer

go deeper