fix(shared): reject HTTP status codes outside the 100-599 range#110554
Merged
steipete merged 2 commits intoJul 18, 2026
Conversation
extractHttpStatusMatch only checked Number.isFinite, so 3-digit sequences such as "000", "099", "600", and "999" were accepted as valid HTTP statuses. Downstream code then surfaced them as "HTTP 0" in user-visible messages and fed them into retry/classification branches (e.g. isCloudflareOrHtmlErrorPage checks `code < 500` and `code < 600`). Restrict the extracted code to the IANA HTTP status code range (100-599). Co-authored-by: Patrick Erichsen <[email protected]>
clawsweeper
Bot
added
rating: 🦪 silver shellfish
Contributor
|
Codex review: needs real behavior proof before merge. Reviewed July 18, 2026, 5:35 AM ET / 09:35 UTC. Summary PR surface: Source -2, Tests +87. Total +85 across 2 files. Reproducibility: yes. from source inspection: a three-digit prefix such as 000, 099, 600, or 999 reached HTTP parsing before this branch’s shared range check; no current-main runtime reproduction was independently established here. Review metrics: none identified. Merge readiness Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch. Rank-up moves:
Proof guidance:
Risk before merge
Maintainer options:
Next step before merge
Security Review detailsBest possible solution: Keep one shared 100–599 validation boundary for every text-derived HTTP prefix, then land only after a redacted real formatter/provider-error transcript confirms invalid prefixes are no longer presented or classified as HTTP statuses. Do we have a high-confidence way to reproduce the issue? Yes from source inspection: a three-digit prefix such as 000, 099, 600, or 999 reached HTTP parsing before this branch’s shared range check; no current-main runtime reproduction was independently established here. Is this the best way to solve the issue? Yes for the proposed boundary: centralizing the 100–599 check in extractHttpStatusMatch and reusing it in all discovered text-prefix consumers avoids divergent parser behavior. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against 35754a63ccaf. Label changesLabel justifications:
Evidence reviewedPR surface: Source -2, Tests +87. Total +85 across 2 files. View PR surface stats
What I checked:
Likely related people:
What the crustacean ranks mean
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics. How this review workflow works
Review history (1 earlier review cycle)
|
Contributor
|
Merged via squash.
|
github-actions Bot
pushed a commit
to Desicool/openclaw
that referenced
this pull request
Jul 19, 2026
…claw#110554) * fix(shared): reject HTTP status codes outside the 100-599 range extractHttpStatusMatch only checked Number.isFinite, so 3-digit sequences such as "000", "099", "600", and "999" were accepted as valid HTTP statuses. Downstream code then surfaced them as "HTTP 0" in user-visible messages and fed them into retry/classification branches (e.g. isCloudflareOrHtmlErrorPage checks `code < 500` and `code < 600`). Restrict the extracted code to the IANA HTTP status code range (100-599). Co-authored-by: Patrick Erichsen <[email protected]> * fix(shared): validate all parsed HTTP status prefixes --------- Co-authored-by: Patrick Erichsen <[email protected]> Co-authored-by: Peter Steinberger <[email protected]>
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
2 participants
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.
What Problem This Solves
extractHttpStatusMatchinsrc/shared/assistant-error-format.tsonly checkedNumber.isFinite(code), so 3-digit sequences such as"000","099","600", and"999"were accepted as valid HTTP statuses. Downstream code then:"HTTP 0"or"HTTP 999"in user-visible messages viaformatRawAssistantErrorForUi.isCloudflareOrHtmlErrorPagecheckscode < 500andcode < 600, socode: 0would pass both predicates and skip the Cloudflare code list).The regex
\\d{3}accepts any 3-digit number, but only 100-599 are valid HTTP status codes per RFC 9110.Fix
Add range validation
code >= 100 && code <= 599toextractHttpStatusMatch. BothextractLeadingHttpStatusandextractProviderWrappedHttpStatusbenefit since they share this helper.function extractHttpStatusMatch( match: RegExpMatchArray | null, ): { code: number; rest: string } | null { return null; } const code = Number(match[1]); return null; } return { code, rest: (match[2] ?? "").trim() }; }Evidence
New test file
src/shared/assistant-error-format.test.tscovers both helpers:Regression check on
extensions/ollama/src/stream-runtime.test.ts(which usesextractLeadingHttpStatusfor failover/retry logic):All existing tests pass, confirming valid HTTP statuses (503, 429, 500, etc.) are still correctly extracted.
Co-authored-by: Patrick Erichsen [email protected]