Exercise 1: A Real content_type Property — Possible Solution
====================================================================

THE PROPERTY
------------------------------
    @property
    def content_type(self):
        # CONTENT_TYPE is real, but deliberately NOT prefixed HTTP_
        # per the WSGI/CGI spec, so .headers alone can never see it
        return self.environ.get('CONTENT_TYPE', '')

VERIFIED AGAINST A REAL LIVE REQUEST
------------------------------
A real request sent with both a custom X-Api-Key header and a real
Content-Type: application/json header, read back through a live
wsgiref server:

    headers={'Accept-Encoding': 'identity', 'Host': '127.0.0.1:8821',
             'User-Agent': 'Python-urllib/3.14', 'X-Api-Key': 'secret-123',
             'Connection': 'close'}
    content_type='application/json'

X-Api-Key shows up correctly in headers (it really was sent as
HTTP_X_API_KEY). Content-Type never appears in that same dict, on
either side of adding the fix - but content_type correctly returns
'application/json', because it reads the real, unprefixed CONTENT_TYPE
key directly, the same way content_length already had to.

WHY THIS WORKS AS AN ANSWER
------------------------------
It doesn't patch headers itself to special-case Content-Type - it adds
a second, dedicated property that reads the real unprefixed key
directly, matching the chapter's own content_length property exactly,
and verifies both properties side by side on one real request so the
gap in headers and the fix in content_type are shown together rather
than asserted separately.