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

閱讀 wsgiref.headers.Headers.init 和 wsgiref.handlers.BaseHandler.start_response，然後使用 python -O 重現 CR/LF 情況。完成的標準是，在 -O 下仍然執行標頭驗證，並且相關回歸測試通過；連結的 PR gh-150727 表示工作已經在進行中。