Missing Error Handling in `set_headers` and `set_headers_async`

[nitish-yaddala]

The set_headers and set_headers_async methods currently assume that response.set_header or response.headers assignment always succeeds.

In practice, especially when supporting multiple frameworks (e.g., FastAPI, Flask, Django), setting headers may:

• Fail silently,
• Raise unexpected exceptions (e.g., TypeError, ValueError),
• Encounter immutable response objects.

Affected Code

• set_header(header_name, header_value) — Line 247, Line 275, Line 278
• response.headers[header_name] = header_value — Line 251, Line 282

Recommendation

• Wrap all set_header calls inside try-except blocks.
• Capture at minimum:
  • TypeError
  • ValueError
  • Any web framework-specific exceptions (e.g., attribute errors for immutable headers).
• Log the error or raise a custom error with a meaningful message.
• Ensure header application failures are either safely skipped or fail-fast based on the criticality.

[cak]

Thanks for another detailed report!

We’ve tightened error handling in both set_headers and set_headers_async. Every set_header(...) call and response.headers[...] = ... assignment is now wrapped and will raise a HeaderSetError with clear context (covering TypeError, ValueError, and immutable/unsupported cases via AttributeError). Async setters are handled explicitly (awaited or safely driven with asyncio.run when no loop is running), and we fail fast rather than silently skipping.

This fix will ship in v2.0.