Repository navigation
Conversation
…aseUrl A model provider baseUrl whose host ends in a numeric or 0x label (https://api.123/v1, https://999.1.2.3/v1) is refused at save because the URL parser reads the host as IPv4 and rejects it, but the message only said the value must be an absolute http or https URL, which it is. When the only reason a refused baseUrl fails to parse is that last label (the same text with a name there is accepted), the refusal now adds the gateway routing hint: a numeric or 0x last label parses as IPv4; use four decimal octets from 0 to 255 without leading zeros. Other refusals keep the general message. The same inputs are accepted and refused as before; only the message changes (finding 1346).
Contributor
|
🦞👀 Pull request received. I will update this pull request when review starts. ClawSweeper review blockedAutomated review did not run, so no review verdict was produced. Reason: The input-safety check rejected material in this revision. No detected value, path, or scanner output is reproduced here. Automatic review is on hold, including after source changes. Request a fresh re-review after resolving the failure; maintainers can also release the hold through an intentional scanner-policy update. Next step: If this is a genuine credential, remove and rotate it. If it is an intentional test fixture, a maintainer must review and qualify it. |
freeqaz
had a problem deploying
to
integration-qa-pr
October 14, 2026 14:54 — with
GitHub Actions
Failure
freeqaz
had a problem deploying
to
integration-qa-pr
October 14, 2026 14:54 — with
GitHub Actions
Failure
This was referenced Oct 14, 2026
This branch had an error being deployed
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
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.
Problem
A model provider
baseUrlwhose host ends in a numeric or0xlabel (https://api.123/v1,https://api.0x10/v1,https://999.1.2.3/v1,https://1.2.3.4.5/v1,https://0.0.0.08/v1) is refused on Configuration create and Preset save withConfiguration field /models/providers/<p>/baseUrl must be an absolute http or https URL.The value is an absolute https URL. The real reason is that the URL parser reads such a host as IPv4 and rejects it, so the message gives the user nothing to change.Change
packages/occ/src/model-provider-settings.ts: when abaseUrlis refused,refusedForNumericLastLabelchecks whether its host (as written, Preset variables filled as the baseUrl rule fills them with a name) ends in a numeric or0xlabel, and whether the same text with that label replaced by a name is accepted. Only then the refusal uses the newbaseUrlNumericHostmessage; every other refusal keeps the general or missing-//message. Values with${VAR}references and non-string values are unchanged.packages/occ/src/errors.ts: the new message appends the sentence fix(gateway): refuse routing hostnames that parse as another address #2387 uses for gateway routing hostnames:A numeric or 0x last label parses as IPv4; use four decimal octets from 0 to 255 without leading zeros.The message names the field and never the value.docs/reference/configuration.md: one clause on the hint.model-auth.ts) do not refuse an unparsable host, so they have no generic parse-failure message to change.No behavior change: the same inputs are accepted and refused before and after; only the message text differs.
Verification
validateModelProviderSettingsover 120,174 cases: the five values above, trailing dots,0X, ports, userinfo, query/fragment/backslash, tabs and surrounding spaces, percent-encoded and fullwidth digits, valid names, dotted quads, shorthand IPv4 (127.1,0x10), IPv6 (valid and invalid), garbage,${VAR}forms, non-string values, Preset literals, and 60,000 random URL-ish strings, at provider and model level. 0 divergences in accept/refuse, error class or field path; 2,692 messages gained only the hint. Kept the general message:https://api.123:99999/v1,https://a b.123/v1,https://api.%31%32%33/v1,ftp://api.123/v1,not a url,https:///v1.tests/integration/configuration-controller.test.mjs(Configuration create: provider and modelbaseUrl,0x, out-of-range octet, five labels, leading-zero octet with a trailing dot; Preset save: literal host with a path variable, modelbaseUrl). With main's source, the test fails on the first new row, and each new row's input gives main's general message (checked per row). One control row,https://api.123:99999/v1, keeps the general message.configuration-controller.test.mjsandocc-api.test.mjs299/299;tsc --buildclean; eslint and prettier clean on touched files.Risks
Low. Message-only change for an input set that was already refused; the hint check runs only on the refusal path, in time linear in the value's length.