Accept Unicode str values in parse_options_header - #321
Conversation
Sorry, something went wrong.
The function already takes str, but encoding as latin-1 raised UnicodeEncodeError for filenames like 中文.doc. Fall back to UTF-8 when latin-1 cannot represent the value.
Merging this PR will not alter performance✅ 5 untouched benchmarks Comparing gyanu2507:fix/parse-options-header-unicode (4b35e58) with main (d9cb4c6) Footnotes
|
Sorry, something went wrong.
There was a problem hiding this comment.
No issues found across 3 files
You’re at about 97% of the monthly reviewed-line limit. You may want to disable incremental reviews to conserve quota. Reviews will continue until that limit is exceeded. If you need help avoiding interruptions, please contact contact@cubic.dev.
Sorry, something went wrong.
parse_options_header already takes str | bytes | None, but a str with characters outside Latin-1 raises UnicodeEncodeError. That's the filename case people actually hit:
Bytes (the WSGI path) were already fine. For str this encodes as Latin-1 when it fits and falls back to UTF-8 otherwise, so the public API matches its type hint.
The issue asked which of the three options you wanted. I went with supporting Unicode str rather than a clearer error, because the signature already accepts str and that's what callers pass for filenames. Happy to switch to a dedicated error if you'd rather keep the Latin-1-only contract explicit.
Fixes #319