Challenge 3: Spot the Missing Header — Possible Solution
====================================================================

THE PROBLEM
------------------------------
Without a Content-Type header, the server has no reliable way to know
HOW to interpret the bytes in the request body. The body might
genuinely be JSON, but it could just as easily be plain text, a URL-
encoded form, or XML — from the server's point of view, a body with
no Content-Type is just an undifferentiated blob of bytes. Many server
frameworks default to NOT parsing the body as JSON unless explicitly
told to via this header, meaning the request could arrive at the
server's handler with an empty or unparsed body even though the JSON
was sent correctly — a frustrating bug that looks like "the data just
didn't arrive" when it actually did, just unrecognized.

THE FIX
------------------------------
Add the header:

  Content-Type: application/json

This tells the server explicitly: "the body you're about to read is
JSON — parse it as such." Some HTTP client libraries add this header
automatically when you pass in a JSON-shaped object, which is why this
mistake often shows up specifically when someone is constructing a
raw request by hand (e.g. with a low-level HTTP call, or a tool like
curl) rather than using a library that infers it for them.

WHY THIS WORKS AS AN ANSWER
------------------------------
This challenge is testing the point made in the chapter that headers
aren't just decorative metadata — some of them are load-bearing.
Content-Type is a clear example: the body's bytes are IDENTICAL either
way, but the server's behavior differs completely depending on what
this one header says. A missing or wrong Content-Type is one of the
most common real-world causes of "my API call isn't working" bug
reports, precisely because the request looks fine at a glance if you
only check the body.