gh-158225: Fix wsgiref Headers __setitem__ validation order

[Tony123-tech]

• Issue: wsgiref.headers.Headers.__setitem__ deletes the old header before validating the new value #158225

[sergiolpzgmz]

Hi!

I reviewed and tested this change locally.

Specifically, I checked that when validation of the new header name or value fails, the existing header value is preserved:

from wsgiref.headers import Headers

h = Headers([("Content-Type", "text/html")])

try:
    h["Content-Type"] = True
except AssertionError:
    pass

assert h.get("Content-Type") == "text/html"

I also checked the case where validation of the header name fails because it contains a control character:

from wsgiref.headers import Headers

h = Headers([("Content-Type", "text/html")])

try:
    h["Content-\x00Type"] = "application/json"
except ValueError:
    pass

assert h.get("Content-Type") == "text/html"

In both cases, the existing header remains unchanged.

I also ran the relevant test suite:

$ ./python -m test test_wsgiref

== Tests result: SUCCESS ==

1 test OK.
Total tests: run=47
Result: SUCCESS

I didn't find any issues with the change in these checks.

[Tony123-tech]

Good question. The realistic case is middleware or frameworks that build headers from user input. If a caller passes a non-string value (e.g. int, None) — which happens with sloppy request parsing — the current code silently drops the existing header rather than raising before mutating. That's the "surprising mutation on failure" pattern.

If you'd prefer not to change behavior, I'm fine closing the PR. Otherwise the fix is small and validated.

[Tony123-tech]

Fair enough — I don't have a real-world case. Closing this. Thanks for the review