skip to content

The Postman collection format declares protocolProfileBehavior with no properties, so which component defines its legal keys?

level: middleimportance: should knowfreq 26%

answer

  1. The schema declares an object, nothing more
  2. Any key validates, including a typo
  3. The runtime holds the only real list
  4. PPB_OPTS resolved against defaultOpts
  5. Declaration and implementation live apart

basics

~10 s

The runtime does. The collection format's schema declares protocolProfileBehavior as an object with no properties, so any key validates; the runtime's PPB_OPTS list is the only real enumeration, resolved against the runtime's own defaults.

solid answer

~40 s

This is a **declaration-versus-implementation** split. The **format's schema** declares `protocolProfileBehavior` as an object and stops there — it lists no properties at all, so any key you write inside it is structurally valid and a misspelling passes validation silently. The **runtime** holds the only real enumeration: `PPB_OPTS` names `strictSSL`, `disableCookies`, `maxRedirects`, `followRedirects`, `insecureHTTPParser`, `followAuthorizationHeader`, `followOriginalHttpMethod`, `removeRefererHeaderOnRedirect` and `protocolVersion`, and `resolveWithProtocolProfileBehavior()` resolves the declared members against `defaultOpts`. So the answer to *is this key legal?* is never in the file or its schema; it is in whatever executes the collection. Say it with the right authority: the file **declares** the block, the runtime **defines** its members.

code

json · 8 lines
json
{
  "name": "checkout",
  "protocolProfileBehavior": {
    "strictSSL": true,
    "folowRedirects": false
  },
  "request": { "method": "POST", "url": "https://example.test/checkout" }
}

go deeper

for a junior

Be ready to recall that the member names come from whatever runs the collection, not from the file's schema, and that a misspelled key inside the block will not be reported to you.

for a middle

Be ready to explain the split precisely: the schema declares an object with no properties, the runtime's PPB_OPTS is the only enumeration, and members are resolved against the runtime's defaults at send time.

for a senior

Be ready to reason about the silent failure. Explain how a typo produces a symptom far from its cause, and describe the review or lint step you would add because no validator covers this field.

for a principal

Be ready to weigh the portability angle: a behaviour that depends on the executing runtime rather than the declared format is a coupling, and you should be able to argue where that coupling is acceptable.

## Two authorities, one field `protocolProfileBehavior` is the clearest example in the Postman world of a field whose **declaration and implementation live in different projects**: - the **collection format** declares the field. A file may carry it, and that is all the format says. - the **runtime** implements it. It decides which members exist, what they do, and what happens when one is absent. Most fields of the format are declared with an enumerated shape — a member list, a type, an enum of allowed values. This one is not, and that asymmetry is the whole question. ## What the format's schema says The schema entry for `protocolProfileBehavior` describes an **object with no properties at all**. There is no member list to check a file against. The practical consequences follow directly: - any key name inside the block is structurally valid; - a misspelled member produces **no validation error** — nothing rejects it and nothing warns; - a value of the wrong type for a member is not caught by the schema either; - reading the schema tells you the field exists and nothing about what may go in it. ## What the runtime knows The runtime carries `PPB_OPTS`, the sole enumeration of members that do anything: - `strictSSL` - `disableCookies` - `maxRedirects` - `followRedirects` - `insecureHTTPParser` - `followAuthorizationHeader` - `followOriginalHttpMethod` - `removeRefererHeaderOnRedirect` - `protocolVersion` At send time `resolveWithProtocolProfileBehavior()` takes the block that came out of inheritance and resolves those members against the runtime's `defaultOpts`, so every member the run needs has a value whether or not the file declared one. A key that is not in `PPB_OPTS` is simply not consulted. ## The gap, in a table | Question | Where the answer is | Where it is **not** | |---|---|---| | May a file carry `protocolProfileBehavior`? | the format's schema | — | | Which member names are legal? | the runtime's `PPB_OPTS` | the schema, which lists none | | What happens if a member is absent? | the runtime's `defaultOpts` | the file | | What happens to a misspelled key? | nothing — it is ignored at send | no validator flags it | | Which declaration of a member wins? | the SDK's resolver, nearest wins | — | ## Consequences you can predict 1. **Validation is not verification.** A collection that validates cleanly may contain a behaviour block that does nothing at all. Passing a schema check proves the file is well-formed, not that the switch you meant is in force. 2. **The failure mode is silence.** A typo does not raise an error; the entry simply keeps whatever the inherited value or the runtime default was, and the symptom appears far from the cause. 3. **Portability is a runtime question.** Whether a member is honoured depends on what executes the collection, not on which format generation the file claims in its `info.schema` URL. 4. **Reviews cannot rely on tooling here.** A reviewer must compare the block against the runtime's member list by hand, because no schema check will do it for them. ## Reviewing a collection file with this in mind - Read the member names in a `protocolProfileBehavior` block character by character; casing matters and nothing else will check it. - Treat an unfamiliar member name as a defect until it is found in the runtime's list, not as a feature you have not met. - Prefer declaring a switch at the level where the intent is obvious, since the failure mode is silent and a scattered override is hard to spot later. - Do not argue about legality from the schema. It genuinely has no opinion. ## Where the answer stops This is a question about **who defines the key**, not about what the key does on the wire. What following a redirect re-sends, what a certificate check proves, what a cookie attribute means and how connections are reused are settled by the HTTP, TLS and cookie topics. Likewise, the shared cookie store, the proxy list with its bypass test, and matching a certificate to a target URL belong to the neighbouring transport topics; this field keeps only the switches themselves and the question of which declaration of one wins.

  • How would you catch a misspelled member in a collection before it reaches a run?
    Nothing in the format catches it, so the check has to be yours: lint the block against the runtime's member list in review or in a small script over the file, and treat any name not on that list as a defect. Schema validation will pass either way, so do not rely on it.
  • If a member is declared nowhere in the file, what value does the run use?
    The runtime's own. `resolveWithProtocolProfileBehavior()` resolves the merged block against `defaultOpts`, so every member `PPB_OPTS` names has a value at send time regardless of what the collection declared.

saying these in an interview costs you the question

  • Claiming the format's schema enumerates the legal members
  • Expecting validation to reject an unknown member name
  • Assuming a typo raises an error at run time
  • Treating schema validity as proof the switch took effect
  • Attributing PPB_OPTS to the collection format rather than the runtime