wsgiref.headers.Headers control-character validation is skipped under -O

wsgiref.headers.Headers.__init__ checks header names and values for control characters only inside an if __debug__: block:

self._headers = headers
if __debug__:
    for k, v in headers:
        self._convert_string_type(k, name=True)
        self._convert_string_type(v, name=False)

Running with -O/-OO sets __debug__ to False, so the loop is skipped and the constructor stores the headers without validation. wsgiref.handlers.BaseHandler.start_response builds its response headers exactly this way (self.headers = self.headers_class(headers)), and those headers are later written to the wire unchanged. A value carrying CR/LF therefore passes through and can split the response or inject headers when an application reflects untrusted input into a header.

$ python -O -c "from wsgiref.headers import Headers; print(bytes(Headers([('Foo','bar\r\nSet-Cookie: evil=1')])))"
b'Foo: bar\r\nSet-Cookie: evil=1\r\n\r\n'

Under a normal build the same call raises ValueError. Every other Headers mutator (__setitem__, add_header, setdefault) validates unconditionally; only the constructor gates the check on __debug__.

Linked PRs

• gh-150727

Read wsgiref.headers.Headers.init and wsgiref.handlers.BaseHandler.start_response, then reproduce the CR/LF case with python -O. Done means header validation remains enforced under -O and the relevant regression tests pass; linked PR gh-150727 indicates work is already underway.