fix(internal): lowercase header names with locale-pinned en-US rule#1933
Open
tsushanth wants to merge 1 commit into
Open
fix(internal): lowercase header names with locale-pinned en-US rule#1933tsushanth wants to merge 1 commit into
en-US rule#1933tsushanth wants to merge 1 commit into
Conversation
Closes openai#1928. `String.prototype.toLowerCase()` applies the host locale to certain Unicode mappings. On a Turkish process locale the uppercase `I` in `OpenAI-Organization` becomes the dotless `ı`, producing `openaı-organization`, which fails Node's HTTP token validation (`TypeError: Header name must be a valid HTTP token`) and tears down the request before it is ever sent. The same surface — header-name lowercasing for matching purposes — also appeared in the log redactor in `src/internal/utils/log.ts`. There the consequence is more subtle but more serious: an `Authorization` header arriving as `authorızatıon` after the Turkish casing rule never matched the redaction list, so the bearer token leaked into the logged request representation. Replace both with `name.toLocaleLowerCase('en-US')`, which keeps the casing rule on the locale-invariant ASCII path regardless of the runtime environment. HTTP header names are RFC-9110 ASCII so en-US is the right anchor. Adds a regression test in `tests/buildHeaders.test.ts` that monkey- patches `String.prototype.toLowerCase` to mimic the Turkish casing rule, then confirms the resulting canonical key is still `openai-organization` and ASCII-only.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
Closes #1928.
`String.prototype.toLowerCase()` applies the host locale to certain Unicode mappings. On a Turkish process locale the uppercase `I` in `OpenAI-Organization` becomes the dotless `ı`, producing `openaı-organization`, which fails Node's HTTP token validation (`TypeError: Header name must be a valid HTTP token`) and tears down the request before it is ever sent. The reporter traced this all the way to `src/internal/headers.ts:77` and verified the workaround.
I also looked at the other call sites where this SDK lowercases header names for matching, and found the redactor in `src/internal/utils/log.ts` does the same thing on the same hot path. There the consequence is more subtle but more serious: an `Authorization` header arriving as `authorızatıon` after the Turkish casing rule never matches the redaction list, so the bearer token would be written verbatim into the logged request representation. Worth fixing in the same PR since it's the same root cause and a security-shaped exposure.
What
HTTP header names are RFC 9110 ASCII so anchoring on en-US is the correct invariant.
Tests
`tests/buildHeaders.test.ts` — new `lowercases header names with ASCII rules even under a Turkish process locale` test. Monkey-patches `String.prototype.toLowerCase` for the duration of the test to mimic the Turkish casing rule (`I` → `ı`), then verifies the canonical key in the resulting `NullableHeaders` is `openai-organization` and ASCII-only.
`yarn jest tests/buildHeaders.test.ts` → 11 passed. `yarn jest tests/log.test.ts` → 4 passed.
Stainless note
This change is in `src/internal/`, which is generated by Stainless. I considered whether the right path was to wait for the upstream codegen change. Felt it was worth proposing the diff directly anyway because (a) the bug currently corrupts requests / leaks credentials in production on a non-trivial install base, (b) the fix is mechanical and easy to mirror in the generator template, and (c) precedent from openai/anthropic SDK repos suggests external PRs to generated paths are merged when correctness-shaped.
Happy to defer to whatever process you'd prefer for landing this — let me know if you'd like the change in a different form.