Mention header name error message for invalid header encodings #3400

Activity

1. lovelydinosaur commented on Nov 12, 2024

   

   lovelydinosaur

   on Nov 12, 2024

   Member

   More actions

   Would you be able to review what range of characters the h11 package uses for valid HTTP headers?
   (Because it's correct, and because it's what we use for the default underlying transport so we may as well be consistent at the higher level abstraction.)
2. jasonkaedingrhino commented on Nov 25, 2024

   

   jasonkaedingrhino

   on Nov 25, 2024

   More actions

   Would you be able to review what range of characters the h11 package uses for valid HTTP headers?
   (Because it's correct, and because it's what we use for the default underlying transport so we may as well be consistent at the higher level abstraction.)

   From https://github.com/python-hyper/h11/blob/master/h11/_headers.py

   # Facts
   # -----
   #
   # Headers are:
   #   keys: case-insensitive ascii
   #   values: mixture of ascii and raw bytes
   #
   # "Historically, HTTP has allowed field content with text in the ISO-8859-1
   # charset [ISO-8859-1], supporting other charsets only through use of
   # [RFC2047] encoding.  In practice, most HTTP header field values use only a
   # subset of the US-ASCII charset [USASCII]. Newly defined header fields SHOULD
   # limit their field values to US-ASCII octets.  A recipient SHOULD treat other
   # octets in field content (obs-text) as opaque data."
   # And it deprecates all non-ascii values
   

   So it's essentially direct-quoting from HTTP/1.1 spec, and thus the choice of ascii encoding makes sense.
3. jasonkaedingrhino commented on Nov 25, 2024

   

   jasonkaedingrhino

   on Nov 25, 2024

   Last edited by jasonkaedingrhino

   More actions

   In the main, these sorts of situations are going to happen when using authentication headers, which are often obtained via some sort of "secret management" process that includes encryption/decryption and/or base64 encoding/decoding along the way before such values get injected into actual code. This leaves the door open for upstream human errors to propagate down into this level while not being "obvious" due to the opaque nature of it all.

   While the example above is very contrived using Cyrillic alphabet, the real error source was more like some bad copy/paste of the correct value.
4. suojae

   added 2 commits that reference this issue on Oct 25, 2025

   Improve error message for non-ASCII header encoding errors

   ...

   This issue will close once commit e5e4a3e is merged into the 'master' branch.

   e5e4a3e

   Improve error message for non-ASCII header encoding errors

   ...

   This issue will close once commit 80b911e is merged into the 'master' branch.

   80b911e
5. jamesrziggy

   added a commit that references this issue on Feb 13, 2026

   fix: improve error messages for non-ASCII header encoding failures

   ...

   e19a44c
6. worksbyfriday

   added a commit that references this issue on Feb 18, 2026

   Include header name in UnicodeEncodeError for invalid header values

   ...

   This issue will close once commit a23676e is merged into the 'master' branch.

   a23676e
7. Maurenz2530 commented on Sep 26, 2026

   

   Maurenz2530

   on Sep 26, 2026

   More actions

   I implemented the focused fix in my fork: invalid ASCII header values now include the header name in the existing UnicodeEncodeError, with coverage for mapping and iterable inputs. Branch: https://github.com/Maurenz2530/httpx/tree/improve-header-encoding-error. Tests: py -m pytest tests/models/test_headers.py -q (29 passed).
8. Maurenz2530 commented on Sep 26, 2026

   

   Maurenz2530

   on Sep 26, 2026

   More actions

   The branch is ready for review: https://github.com/Maurenz2530/httpx/tree/improve-header-encoding-error. GitHub's PR API does not allow my account to create the upstream PR, so the direct comparison page is: master...Maurenz2530:improve-header-encoding-error