How does a web framework look up a body parser by media type, and when does a lookup miss become a 415?
answer
- a table lookup, not a parser chain
- parameters are not part of the key
- suffix fallback for vendor types
- route-declared types filter first
- the miss lands during binding
basics
~20 sThe framework strips parameters from the Content-Type value, lowercases the type and subtype, and looks that key up in a parser registry, falling back to a structured suffix or a wildcard. A miss yields 415 before the handler runs.
solid answer
~40 sBody parsers are held in a registry keyed by media type, and each registration says which types it can read. On a request the framework takes the `Content-Type` value, splits off parameters such as `charset`, and lowercases the remaining `type/subtype` — parameters are not part of the key. It tries an exact match first, then a **structured suffix** fallback so `application/vnd.example.order+json` can reuse the JSON parser, then any wildcard entry registered as a catch-all. A route that declares which types it consumes narrows the candidate set before the lookup even runs. Because binding happens before the handler body executes, a miss is a **415 Unsupported Media Type** raised at the boundary: the handler is never invoked, and nothing half-parsed reaches it.
go deeper
Remember that a body parser is chosen by media type from a registry, and that when nothing matches the framework answers 415 on its own before your handler is called.
Be able to walk the lookup: strip parameters, lowercase, exact match, structured-suffix fallback, wildcard last, with route-declared consumed types filtering the set beforehand.
Show how you diagnose a 415 spike: log the raw header with the route, compare against the route's consumed types, and suspect a client or proxy header change before suspecting the payload.
Own the policy. Decide whether a catch-all parser may be registered at all, since it converts a precise boundary rejection into a late failure, and decide which media types the platform accepts as a whole.
## The registry, and what each entry knows A framework keeps body parsers — also called readers, converters or deserializers — in a registry. A registration carries at least: - the **media types it can read**, as exact types, suffix patterns, or a wildcard; - the **target shapes it can produce** (an arbitrary object tree, a map of strings, raw bytes, a stream); - a **position or priority** that breaks ties when more than one entry can serve a type. Selection is a table lookup with a small fallback ladder, not a chain of parsers each trying and failing. That matters operationally: the outcome is decided before a single body byte is consumed, so a rejected request costs nothing. ## Building the lookup key The `Content-Type` header field value is not used verbatim. Given `application/json; charset=utf-8`, a typical framework will: 1. split the value at the first `;`, keeping **`application/json`** and setting the parameters aside; 2. lowercase and trim it, since type and subtype are case-insensitive; 3. look that key up in the registry; 4. on a miss, retry with the **structured suffix**: `application/vnd.example.order+json` falls back to the JSON parser via `+json`; 5. on a further miss, try a registered wildcard entry (`application/*` or `*/*`) if one exists — typically a raw-bytes parser. Parameters are not part of the key. `charset` is an instruction to the *chosen* parser about decoding, and `boundary` is an instruction about splitting; neither should change which parser is chosen. A framework that keys on the whole header value needs a separate entry per charset, which is a configuration smell. | Header value | Lookup key | Resolved by | |---|---|---| | `application/json` | `application/json` | exact match | | `application/json; charset=utf-8` | `application/json` | exact match, parameter set aside | | `APPLICATION/JSON` | `application/json` | exact match after lowercasing | | `application/vnd.example.order+json` | `application/vnd.example.order+json` | suffix fallback to the JSON parser | | `application/octet-stream` | `application/octet-stream` | raw or wildcard entry | | `application/x-unknown` | `application/x-unknown` | no entry — the miss path | ## What narrows the candidate set A route can declare the media types it consumes. That declaration is a filter applied *before* the registry lookup: even if a parser for `text/plain` is registered globally, a route that consumes only `application/json` rejects a `text/plain` body. This is the difference between "the server can read this format somewhere" and "this endpoint accepts this format", and it is the usual reason a body that works on one route is refused on another. When the header is absent there is no key to look up at all. Frameworks differ here: some apply a configured default type, others treat the request as having an unsupported body. Either way the decision is made at the same boundary. ## Where the failure lands Body parsing is part of **argument binding**, which runs between routing and the handler invocation. A miss therefore surfaces as **415 Unsupported Media Type** produced by the framework, not by application code. Three consequences follow: - the handler is **not** invoked, so it cannot observe or repair a mislabelled body; - no partially-parsed value exists, so there is no half-populated object to leak into business logic; - the error is uniform across every route, which is what makes 415 a reliable signal in logs. Two refinements are worth stating. First, some frameworks bind lazily — the parse happens on first access to the argument — which moves the failure a few microseconds later but keeps it inside the framework's error mapping. Second, a wildcard catch-all parser suppresses 415 entirely: if `*/*` maps to a raw-bytes reader, nothing is ever unsupported, and the failure reappears later as a confusing error deep in application code. Registering a broad catch-all is a decision to trade an early, precise 415 for a late, vague failure. ## Diagnosing it in production A sudden burst of 415 responses almost always means the *label* changed, not the payload: a client library upgraded and started appending or dropping a parameter, a proxy rewrote the header, or a new route declared a narrower consumed type than the old one. Log the raw header value alongside the route on every 415 — without it you are guessing, because the body itself usually looks perfectly valid.
- Why should the charset parameter not participate in parser selection?Because it describes how the chosen parser decodes bytes into text, not which format the body is in. Keying on it would require a separate registration per charset and would refuse a perfectly readable body merely because a client spelled the parameter differently. Select on type and subtype; hand the parameters to the parser.
- What does registering a wildcard catch-all parser cost you?It removes 415 as a signal. With a `*/*` entry every media type resolves to something, so a mislabelled or genuinely unsupported body is accepted and fails later inside application code with a vaguer error. That trade is sometimes deliberate for proxy-style endpoints, but it should be a conscious decision, not a default.
- A route works in one service and returns 415 in another with the same body. Where do you look first?At the route's declared consumed types and at the exact header value on the wire. The usual causes are a route that accepts a narrower set than you assumed, or a client or proxy that changed the parameter portion of the header. Compare the logged header value between the two environments before touching the payload.
saying these in an interview costs you the question
- Thinks the whole Content-Type value including parameters is the registry key
- Says parsers are tried one by one until one succeeds
- Believes the handler runs first and rejects the body itself
- Assumes a globally registered parser makes every route accept that type
- Treats a catch-all wildcard parser as a free safety net