[mofr]

Stacked on #347.

What

• A response header is a str (as is), an int (a number) or a datetime (an HTTP-date in GMT), the types HTTP has a format for. The format follows the type only: a datetime is an HTTP-date in Last-Modified and in X-Updated-At alike, no longer ISO 8601 in headers other than Last-Modified.
• ResponseHeader[T] of another type raises TypeError on import: a UUID or an enum is set as a str (str(uid), status.value).
• set checks the value against T (closes the TODO of Add type validation for response headers #136): a bool or an enum is rejected even where it subclasses int or str, and a datetime without a time zone raises ValueError instead of being read as the server's local time.
• The HTTP-date is formatted with email.utils.format_datetime, which does not depend on the locale of the server, as strftime('%a, %d %b …') did.
• response_headers_serializer, ResponseHeaderSerializer, both built-in serializers and winter.web.initialization are gone. The headers of a response are strings from the moment they are set.
• The problem handler set a MediaType object into a ResponseHeader[str]; it sets its string now.

Why

The registry chose the format by the header name inside Winter, so the same datetime came out in two formats, and its fallback str() sent Status.ACTIVE or True to clients without an error. HTTP defines strings, numbers and dates for header values, so a closed set of types covers what Winter can format, and every other type is built outside from public pieces through str.

To be confirmed on the consumer: how many headers are set with values that are not strings, and which of them are datetimes in custom headers that change from ISO 8601 to HTTP-date.

🤖 Generated with Claude Code