Header names, values & content types

Headers carry metadata. Content-Type describes a message representation; Accept expresses which response representations a client is willing to receive. Neither field alone guarantees that a body actually has the promised syntax or shape. An API client still checks bytes, decoding and its schema. For example, a broken service can return an HTML error page despite the client asking for JSON.

HTTP field names are case-insensitive. Content-Type and content-type name the same field. Field values have their own grammar: changing the case of an authorization token or request identifier can change its meaning. Do not implement header handling by lowercasing every string in the message.

A list of name/value pairs preserves repeated fields. A dictionary can erase earlier values before the client sees that the metadata was ambiguous. Some HTTP fields support combining values under defined rules; others, such as Set-Cookie, need separate treatment. This lesson's helper handles a selected singleton: missing is None, one match returns a value, multiple matches raise ValueError. It is not a universal header-combination algorithm.

fields = [("x-request-id", " \tAbC-9\t "),
          ("content-type", "Application/JSON; charset=utf-8")]
matching = [value.strip(" \t") for name, value in fields
            if name.lower() == "x-request-id"]
print(matching)  # ['AbC-9']; preserve case inside the value

Strip only outer space and tab for header_value. An empty value after trimming is still a present field. if not value loses that distinction. The build also rejects CR or LF anywhere in supplied field names or values, even unrelated fields, rather than allowing those separators to masquerade as ordinary metadata. Other name syntax is guaranteed by the input contract; this structured helper does not parse raw HTTP header sections.

Content-Type introduces another grammar. In Application/JSON; charset=utf-8, the media-type essence is Application/JSON; the semicolon starts parameters. For this API, content_is_json compares the stripped, lowercased essence exactly against application/json. A substring check would wrongly accept application/jsonp. A whole-value check would wrongly reject parameters.

Structured suffixes such as application/problem+json are useful in real APIs, but this exercise deliberately recognizes only application/json. A different endpoint can declare a broader supported set. Likewise, recognizing a charset parameter does not prove its correctness or decide how this API handles encoding; the JSON lesson explicitly requires UTF-8.

Before implementing the helper, list the expected results for a missing field, a present empty field, differently cased names and duplicate Content-Type fields. Then include a repeated unrelated field and verify that it is allowed. Keep the value's internal whitespace intact. The bugs isolate name matching and parameter handling, and the build requires both operations to work together without mutating the original pairs.

The field-name, field-value and media-type rules come from RFC 9110 sections 5 and 8.3. The lab's strict singleton choice resolves ambiguity for this API rather than claiming every HTTP field has that policy.