Conversation
A deployment default model provider had to use https, with no exception:
validModelProviderBaseURL compared the scheme against a single "https"
constant, so PUT /core/v1/harnesses/{harness}/model-configuration rejected a
reachable local endpoint with model_provider_base_url_invalid.
Plain HTTP is already acceptable elsewhere on this path. MiniMax-AI#408 let
OAC_PUBLIC_URL use it on loopback and private ranges, and the credential
gateway added in MiniMax-AI#343 serves the Harness over loopback in plaintext by
design: the Harness never holds the key, so the relay is a local HTTP
service. The provider base_url was the one remaining surface that mapped
http to invalid unconditionally.
Admit http only where the URL cannot leave the host: localhost, or a
loopback IP. A private-network address stays HTTPS because other hosts can
reach it. https keeps working everywhere it did, and credentials, query and
fragment are still rejected on both schemes.
Docs, the console error copy, the e2e fixture that mirrors Core's rule, and
the contract and Core API tests follow.
A deployment default model provider could only use https, with a loopback-only exception for http. That blocked a legitimate setup: a self-hosted provider on another host in the same network, reachable only over plain HTTP. The scheme now carries no admission decision. Core admits http and https on any host, and the Runtime-side provider validation in internal/modelprovider matches. Host, port, credential, query, fragment and control-character checks are unchanged. The operator owns the endpoint, so the transport choice is theirs. - contracts/agents-api/v1/model_provider_admission.go: replace the loopback scheme branch with an admitted-scheme set - contracts/agents-api/v1/model_execution.go, contract docs (EN/ZH), console i18n and the e2e fixture: reword the error to name http and https without a loopback qualifier - tests: remote http is now an accepted URL; the invalid-URL cases use an unsupported scheme instead
velrith
changed the title
The admission rule widened to http in the previous commits, but the console client still rejected any stored base URL that was not https. Core accepted an http configuration while /core/v1/harnesses failed projection, so the console showed "Core returned an invalid administration response" for the whole harness list and the deployment default model configuration could not load. Widen the client-side pattern to http/https, mirroring the Core write rule, and update the tests that encoded the https-only contract.
The console's write form still enforced the old HTTPS-only rule in isProviderUrl, so saving an operator-chosen http endpoint was blocked before the request reached Core. The rejection text also still told the administrator to use HTTPS, and the example was a public host. Widen the form check to http/https, update the guidance text and example, and cover the accepted and rejected shapes.
This branch has not been 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
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.
Fixes #416.
A deployment default model provider had to use
httpswith a single exception:httpon a loopback host. That still blocks a self-hosted provider on another host, which is a normal setup and often only speaks plain HTTP.This removes the scheme from the admission decision entirely.
httpandhttpsare both accepted on any host, including private and public ones. Everything elsevalidModelProviderBaseURLalready enforced is unchanged: a usable host, a port in range, and no credentials, query, fragment or control characters.internal/modelprovider/config.gohad the same loopback-only rule on the Runtime side; it now admits both schemes too, so a frozen bundle that Core accepts cannot be rejected later by the Harness.Not weakened by this change
https://user:pass@host) are still rejected.?queryand#fragmentare still rejected.ftp://,file://, scheme-relative//host) are still rejected.Why no scheme restriction
The operator owns the endpoint. Refusing plain HTTP for an address the operator explicitly configured does not protect the key: they can already serve that same endpoint over TLS if they want, and the choice of transport between Core and their own provider is theirs to make. Keeping the rule meant a local-network provider was simply unusable.
Files
contracts/agents-api/v1/model_provider_admission.go: admitted-scheme set replaces the loopback scheme branchinternal/modelprovider/config.go: acceptshttpandhttpsfor the frozen bundlecontracts/agents-api/v1/model_execution.go,contracts/agents-api/{,zh/}model-execution.md,contracts/agents-api/{,zh/}core-errors.md, console i18n (en,zh-CN) andapps/web/e2e/fixture-console.mjs: the error now names both schemes without a loopback qualifiercontracts/agents-api/v1,services/core/internal/api,internal/modelprovider,apps/daemon/internal/agent/mcodeandapps/daemon/internal/agent/claudesdk: remotehttpis now an accepted URL, and the invalid-URL cases use an unsupported schemeVerification
go test ./contracts/... ./internal/... ./services/core/internal/api/... ./apps/daemon/...all passpnpm test:webpasses (70 files, 392 tests)http://10.0.0.5:8080/v1,http://192.168.1.10/v1,http://172.16.4.4:7351,http://[fd00::1]/v1andhttp://model_gateway.internal/v1are now accepted, whileftp://,file://,//host, embedded credentials, query, fragment and control characters are still rejected