Skip to content

fix(helpers): make X-AIMock-Strict header parsing case-insensitive and whitespace-tolerant - #408

Open
Ayush7614 wants to merge 1 commit into
CopilotKit:mainfrom
Ayush7614:fix/strict-header-case-insensitive
Open

fix(helpers): make X-AIMock-Strict header parsing case-insensitive and whitespace-tolerant#408
Ayush7614 wants to merge 1 commit into
CopilotKit:mainfrom
Ayush7614:fix/strict-header-case-insensitive

Conversation

@Ayush7614

Copy link
Copy Markdown

Clients, proxies, and shell snippets often emit X-AIMock-Strict: True, TRUE, or true with surrounding whitespace. The previous resolveStrictMode compared literally against "true"/"false"/"1"/"0", so those variants silently fell back to the server default.

On a --strict false server that meant X-AIMock-Strict: True stayed at 404 instead of 503; on a --strict true server X-AIMock-Strict: False stayed strict. The same header also gates reasoning suppression, so the mismatch could surface as flaky reasoning assertions.

Change:

  • Trim surrounding whitespace and lower-case the header value before comparing
  • "true"/"TRUE"/" True " / "1" / " 1 " → strict on
  • "false"/"FALSE"/" false " / "0" / " 0 " → strict off
  • Unrecognised values still fall back to serverDefault

Verified:

  • pnpm run format:check / lint / typecheck clean
  • Manual probe via createServer:
    strict:false + True/TRUE/" TRUE "/1 → 503 (was 404 before on capitalised variants)
    strict:true  + False/FALSE/" FALSE "/0 → 404 (was 503 before)
    unknown "maybe" → falls back to server default
    
  • Existing openrouter-video.test.ts strict-header tests (lower-case) still pass (123 passed)

…d whitespace-tolerant

Clients and proxies often normalize or user-configure header values
with varying case (True/TRUE) or surrounding whitespace. The previous
strict check compared literally against "true"/"false"/"1"/"0",
so "True" or " true " silently fell through to the server default,
causing surprising 404s/503s and reasoning suppression mismatches.

Trim and lower-case the value before comparison so "True", "TRUE",
" true " etc. are accepted. Unrecognised values still fall back to
the server default.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant