What I'm asking for
Let a deployment default model provider be configured with an http:// base_url, instead of requiring https://.
Where it's blocked
contracts/agents-api/v1/model_provider_admission.go:12 hard-codes providerScheme = "https", and validModelProviderBaseURL rejects anything else. So PUT /core/v1/harnesses/{harness}/model-configuration returns 400 model_provider_base_url_invalid for a perfectly reachable local endpoint, e.g. http://127.0.0.1:7351 or http://10.0.0.5:8080.
This is a distinct surface from #398 / #408: those changed the public URL and the node paths. The model provider base_url keeps the unconditional HTTPS rule.
Why this looks inconsistent
The repo already treats plain HTTP as acceptable where it does not leave the trust boundary:
The provider base_url is the one remaining surface that maps http to "invalid" unconditionally, even when the host is the same loopback the gateway already uses.
Concrete case, not hypothetical
I run a self-hosted model proxy on this host (an OpenAI / Anthropic / Responses-compatible gateway on 127.0.0.1:7351) and I want the Harnesses to use it. Today the only way through is to stand up a TLS terminator in front of it and install a self-signed CA into the Runtime image's trust store — extra moving parts for a connection that never leaves the machine.
Suggested shape
Accept http where the same rule the rest of Core already uses says it is safe — loopback, or literal private ranges — and keep https required everywhere else. That mirrors #408 exactly and keeps the current default unchanged. If you would rather make it explicit, an opt-in works too.
I am not asking to drop TLS. A plain-HTTP exception limited to loopback/private hosts would cover the local-proxy case without weakening anything reachable from the network.
What I'm asking for
Let a deployment default model provider be configured with an
http://base_url, instead of requiringhttps://.Where it's blocked
contracts/agents-api/v1/model_provider_admission.go:12hard-codesproviderScheme = "https", andvalidModelProviderBaseURLrejects anything else. SoPUT /core/v1/harnesses/{harness}/model-configurationreturns400 model_provider_base_url_invalidfor a perfectly reachable local endpoint, e.g.http://127.0.0.1:7351orhttp://10.0.0.5:8080.This is a distinct surface from #398 / #408: those changed the public URL and the node paths. The model provider
base_urlkeeps the unconditional HTTPS rule.Why this looks inconsistent
The repo already treats plain HTTP as acceptable where it does not leave the trust boundary:
OAC_PUBLIC_URLaccepthttpon loopback and literal private ranges (internal/origin,deployment/public_url.go).The provider
base_urlis the one remaining surface that mapshttpto "invalid" unconditionally, even when the host is the same loopback the gateway already uses.Concrete case, not hypothetical
I run a self-hosted model proxy on this host (an OpenAI / Anthropic / Responses-compatible gateway on
127.0.0.1:7351) and I want the Harnesses to use it. Today the only way through is to stand up a TLS terminator in front of it and install a self-signed CA into the Runtime image's trust store — extra moving parts for a connection that never leaves the machine.Suggested shape
Accept
httpwhere the same rule the rest of Core already uses says it is safe — loopback, or literal private ranges — and keephttpsrequired everywhere else. That mirrors #408 exactly and keeps the current default unchanged. If you would rather make it explicit, an opt-in works too.I am not asking to drop TLS. A plain-HTTP exception limited to loopback/private hosts would cover the local-proxy case without weakening anything reachable from the network.