Say What the Body Is

read_body now hands handle the exact bytes the client sent. Bytes alone do not say what they are: {"title": "Dune"} could be JSON, a line of text, or the start of something else. The sender says what they are in the Content-Type header, the same header your server already puts on every reply it sends, content-type: application/json. Before your server treats a body as JSON, it checks two things: that the client labeled it JSON, and that the bytes really are JSON.

The media type

A Content-Type value starts with a media type, type/subtype, and may add parameters after a semicolon:

Content-Type: application/json
Content-Type: Application/JSON; charset=utf-8

Both lines label the body application/json. Media type names are case-insensitive, and charset=utf-8 is a parameter, not part of the type. So the media type is the part before the first ;, with spaces stripped, compared in lowercase.

application/json defines no charset parameter at all: JSON exchanged between systems is UTF-8 (RFC 8259, section 8.1). Clients add charset=utf-8 anyway, and it does no harm, so this server ignores every parameter and always decodes JSON as UTF-8.

print("Application/JSON; charset=UTF-8".split(";")[0].strip().lower())

Compare the whole media type, not a piece of it. "json" in value also accepts application/jsonx, and startswith("application/json") accepts application/json-patch+json. That last one is a real media type: types ending in +json (RFC 6839) are JSON with extra rules of their own. This server accepts exactly application/json and refuses the rest. That is its choice, written in SERVICE_CONTRACT.md, not a rule of HTTP.

In the request dict, header names are lowercase and each holds a list of values, so the label is request["headers"]["content-type"][0]. A request may have no label at all; request["headers"].get("content-type", [""]) gives a list holding an empty string then, which matches nothing.

415 or 400

Two different things can be wrong, and each has its own status:

• The label is wrong or missing. The server does not accept that media type, whatever the bytes are: 415 Unsupported Media Type. It never looks at the bytes.

• The label is right, the bytes are not. The body is not UTF-8, or it is not valid JSON: 400 Bad Request, a malformed request.

The two statuses tell the client different things to fix. After a 415 it sends a format this server accepts, labeled as such; after a 400 it fixes the bytes it sends. A server that answers both with 400 leaves the client guessing which one went wrong.

json_body(request) is already in reading_server.py: it returns json.loads(request["body"].decode("utf-8")). Two steps can fail inside it. decode raises UnicodeDecodeError on bytes that are not UTF-8, and json.loads raises json.JSONDecodeError on text that is not JSON. Both are subclasses of ValueError, so one except ValueError: catches both:

That prints {'title': 'Dune'}, then JSONDecodeError, then UnicodeDecodeError. Keep the except that narrow. except Exception: would also turn a mistake in your own code, such as a misspelled key, into a 400 that blames the client.

Do not decode as Latin-1 to make the error go away. Every byte is a Latin-1 character, so that decode never fails, and bytes that are not UTF-8 would be read as the wrong text instead of being refused.

Your task

Write body_error(request) in reading_server.py:

1. Take the media type from the request’s content-type, as above. If it is not application/json, return a 415 response built with json_error.

2. Call json_body(request) inside try. If it raises ValueError, return a 400 response.

3. Otherwise return None.

Like read_body, it returns None or the response to send. Every error reply comes from json_error, so it carries its own content-type: application/json, even when it refuses the client’s label.

No route calls body_error until Lesson 4, so try it from the Shell tab. make_request in tests/test_server.py builds a request dict with a JSON body, a content-type, and a length; the script changes the label of one request and the bytes of another:

python - <<'EOF'
import reading_server
from tests.test_server import make_request

book = {"title": "Dune", "author": "Frank Herbert"}
print(reading_server.body_error(make_request("POST", "/books", book)))
labeled = make_request("POST", "/books", book)
labeled["headers"]["content-type"] = ["text/plain"]
print(reading_server.body_error(labeled)["status"])
broken = make_request("POST", "/books", book)
broken["body"] = b'{"title": '
print(reading_server.body_error(broken)["status"])
EOF

It prints None, 415, and 400.

Then press Check my work. The next lesson steps back from code to decide where a new book goes and what each write answers.