In a Postman collection, what does body.options.raw.language do, and when does it not change the Content-Type sent?
answer
- It labels the raw payload, not the request
- A header can be derived from that label
- The derived header is flagged as supplied by the runtime
- It fills a gap; it never replaces a declared header
basics
~10 sbody.options.raw.language labels what a raw payload is written in. From that label the runtime derives a Content-Type header marked system true, but only when the request declares no Content-Type of its own.
solid answer
~40 s`body.options.raw.language` is an annotation beside a `raw` payload saying what the string is written in, such as `json` or `xml`. It does not change the payload's bytes. At send time the runtime can derive a `Content-Type` header from it, and the header it adds is flagged `system: true` to record that the runtime supplied it rather than the author. The condition matters: the derived header is added **only when the request declares no `Content-Type` header itself**. So a hand-typed `Content-Type` always wins, and re-picking the language on such a request changes the editor and nothing on the wire. When someone says the language setting is ignored, read the declared header list first — that is usually the whole explanation.
code
json · 10 lines{
"header": [
{ "key": "Content-Type", "value": "text/plain" }
],
"body": {
"mode": "raw",
"raw": "{\"id\":1}",
"options": { "raw": { "language": "json" } }
}
}go deeper
Be ready to say that the language names what a raw payload is written in and that a Content-Type can be derived from it. Knowing it is an annotation, not the payload itself, is enough at this stage.
Explain the precedence mechanically: the derived header is added only when none is declared, and it carries a flag marking it as runtime-supplied. Be able to walk the four combinations of declared header and language.
Demonstrate the diagnosis. When a request sends an unexpected content type, read the declared headers before touching the body, and account for pre-send scripts that rewrite headers after the document is read.
Own the convention: decide whether shared collections declare content types explicitly or lean on the derivation, and make the choice consistent so reviewers never have to guess where a request's content type came from.
## What `language` actually is `body.options.raw.language` is an annotation that sits beside a `raw` payload in a stored request and says what that payload is written in — for example `json` or `xml`. It is metadata about the string, not the string itself and not a header. The **collection format** declares the field; nothing about it changes the bytes of `body.raw`. Its visible job is editor-side: it decides how the payload is highlighted and formatted while you look at it. Its interesting job is the one interviewers ask about — it is the input from which a `Content-Type` header can be derived at send time. ## The header the runtime derives, and the flag it wears When a request runs and the raw payload names a language, the **runtime** can add a `Content-Type` header derived from that language. The header it adds is marked `system: true`, which means exactly one thing: *the runtime supplied this header, the author did not declare it*. That flag is how a header the machine contributed stays distinguishable from a header a person typed, in logs, in inspection, and in code that walks the header list. The rule that matters is the condition on the add: **the derived header is added only when the request declares no `Content-Type` of its own.** It fills a gap. It never replaces, never duplicates, and never wins a fight. ## The precedence table | request's own `Content-Type` | `body.options.raw.language` | what goes out | |---|---|---| | absent | set | a `Content-Type` derived from the language, flagged `system: true` | | absent | absent | nothing added by this mechanism | | declared by the author | set | the author's header, untouched — the derivation is skipped | | declared by the author | absent | the author's header, untouched | Read the third row twice. It is the entire question. Once a request carries a `Content-Type` the author put there, re-picking the language changes the highlighting and changes **nothing on the wire**. People lose real time to this: they flip the language back and forth, watch the server keep rejecting the payload, and never look at the header list where the actual answer sits. ## Diagnosing "my language setting is ignored" 1. Look at the request's declared headers first, not at the body. If a `Content-Type` is declared there, that is what is being sent and the derivation was skipped by design. 2. If you want the derived header, remove the declared one. Do not try to out-rank it from the body side; there is no precedence knob. 3. If you want a header the language would never produce, declare it explicitly and accept that the language is now decoration. 4. Remember that scripts running before the send can also edit headers, so a header that appears in neither the document nor the language mapping came from somewhere and that somewhere is code. ## Why the mechanism is built this way Two design instincts are at work, and both are defensible: - **The author's explicit statement wins.** A header someone typed is a decision; a header derived from an annotation is a convenience. Convenience never overrides a decision. - **The convenience is honest about itself.** Because the derived header carries `system: true`, nobody has to guess later whether a `Content-Type` in an inspected request came from the document or from the machine. The provenance travels with the header. The cost of that design is precisely the confusion above: a request can look fully configured on the body side and still send something the body side never mentioned. That is not a bug to be worked around; it is the precedence rule doing its job. ## Things this mechanism does not do - It does not change `body.mode`. A raw payload stays raw no matter what language is named beside it. - It does not validate the payload. Naming a language does not check that the string parses as that language, and a mismatch produces no complaint from this mechanism. - It does not apply to the other modes. `language` lives under `options.raw`, so it is a statement about a raw payload only. - It does not decide what the media type *means* to the server. Which types a server accepts, and how it negotiates among them, is HTTP's own subject. ## The one-sentence version to say out loud `body.options.raw.language` labels a raw payload, the runtime turns that label into a `Content-Type` header marked `system: true`, and it only does so when the request has not declared a `Content-Type` itself — so a hand-typed header always wins, and the fastest way to explain a "wrong" content type is to read the header list before touching the body.
- What does the system flag on that derived Content-Type header tell you when you inspect a request?That the runtime supplied the header rather than the author declaring it. The flag preserves provenance, so anything walking the header list can tell a machine-contributed header from a typed one. It changes nothing about how the header is sent; it only records where it came from.
- A teammate keeps flipping the raw language and the server keeps rejecting the payload. What do you tell them to check?The request's declared header list. If a `Content-Type` is declared there, the derivation is skipped by design and the language is decoration. Remove the declared header to let the derived one apply, or accept the declared one and stop changing the language. Also check whether a pre-send script is rewriting headers.
saying these in an interview costs you the question
- Says the language always overrides a declared Content-Type
- Thinks language changes the payload's bytes or validates it
- Expects two Content-Type headers when both sources exist
- Believes the language applies to non-raw body modes
- Assumes the runtime checks the payload parses as that language