Is there an existing issue for this?
Current Behavior
🛑 failed to fetch results: failed to fetch ids: failed to parse ids: OVHcloud API error (status code 404): Client::NotFound: "Got an invalid (or empty) URL"
- ovhcloud-cli: built from
main (b973d5d)
- go-ovh: v1.9.0
- Endpoint:
https://eu.api.kimsufi.com/1.0 (custom endpoint / Kimsufi EU)
Description
Any CLI command targeting a Kimsufi or SoYouStart endpoint (or any custom, non-official endpoint) fails with a 404 Not Found, even with valid credentials and a correctly configured endpoint.
Example:
ovhcloud --profile=kseu baremetal list --debug -e
GET /v1/dedicated/server HTTP/1.1
Host: eu.api.kimsufi.com
...
HTTP/2.0 404 Not Found
...
🛑 failed to fetch results: failed to fetch ids: failed to parse ids: OVHcloud API error (status code 404)
Root cause
Every API path in this codebase is hardcoded with a /v1/ (or /v2/) prefix, e.g. internal/services/baremetal/baremetal.go:
common.ManageListRequest("/v1/dedicated/server", "", ...)
go-ovh's getTarget helper has a convenience rewrite (ovh/ovh.go):
// getTarget returns the URL to target given and endpoint and a path.
// If the path starts with `/v1` or `/v2`, then remove the trailing `/1.0` from the endpoint.
func getTarget(endpoint, path string) string {
if strings.HasSuffix(endpoint, "/1.0") && (strings.HasPrefix(path, "/v1/") || strings.HasPrefix(path, "/v2/")) {
return endpoint[:len(endpoint)-4] + path
}
return endpoint + path
}
If the configured endpoint ends in /1.0 and the path starts with /v1/, it strips /1.0 from the endpoint and calls the bare domain root instead (e.g. https://eu.api.kimsufi.com/1.0 + /v1/dedicated/server → https://eu.api.kimsufi.com/v1/dedicated/server).
This assumes the gateway also serves a /v1-versioned API directly at the domain root. That's true for eu.api.ovh.com (and ca.api.ovh.com, api.us.ovhcloud.com), but not for eu.api.kimsufi.com / eu.api.soyoustart.com, which only serve the API under /1.0.
Confirmed with curl:
| URL |
Status |
https://eu.api.kimsufi.com/v1/dedicated/server |
404 (route doesn't exist) |
https://eu.api.kimsufi.com/1.0/dedicated/server |
401 (route exists, needs auth) |
https://eu.api.ovh.com/v1/dedicated/server |
401 (works — alias exists here) |
https://eu.api.ovh.com/1.0/dedicated/server |
401 (works) |
Expected Behavior
The command should list dedicated servers on the Kimsufi account, the same way it works for an ovh-eu profile.
Steps To Reproduce
- Create a profile pointing at a Kimsufi (or SoYouStart) endpoint:
ovhcloud login --profile kseu
# pick "Custom endpoint", enter https://eu.api.kimsufi.com/1.0
- Run any command that hits a
/v1/-prefixed path, e.g.:
ovhcloud --profile=kseu baremetal list
Anything else?
Since this is entirely a client-side path-construction issue, it can be fixed without touching go-ovh: wrap the API client so that outgoing paths starting with /v1/ are rewritten to drop that prefix (letting them append under the endpoint's own /1.0 base) whenever the active endpoint isn't one of the 3 official gateways (ovh-eu, ovh-ca, ovh-us). Happy to submit a PR with this fix if useful.Since this is entirely a client-side path-construction issue, it can be fixed without touching go-ovh: wrap the API client so that outgoing paths starting with /v1/ are rewritten to drop that prefix (letting them append under the endpoint's own /1.0 base) whenever the active endpoint isn't one of the 3 official gateways (ovh-eu, ovh-ca, ovh-us). Happy to submit a PR with this fix if useful.
Is there an existing issue for this?
Current Behavior
main(b973d5d)https://eu.api.kimsufi.com/1.0(custom endpoint / Kimsufi EU)Description
Any CLI command targeting a Kimsufi or SoYouStart endpoint (or any custom, non-official endpoint) fails with a
404 Not Found, even with valid credentials and a correctly configured endpoint.Example:
Root cause
Every API path in this codebase is hardcoded with a
/v1/(or/v2/) prefix, e.g.internal/services/baremetal/baremetal.go:go-ovh'sgetTargethelper has a convenience rewrite (ovh/ovh.go):If the configured endpoint ends in
/1.0and the path starts with/v1/, it strips/1.0from the endpoint and calls the bare domain root instead (e.g.https://eu.api.kimsufi.com/1.0+/v1/dedicated/server→https://eu.api.kimsufi.com/v1/dedicated/server).This assumes the gateway also serves a
/v1-versioned API directly at the domain root. That's true foreu.api.ovh.com(andca.api.ovh.com,api.us.ovhcloud.com), but not foreu.api.kimsufi.com/eu.api.soyoustart.com, which only serve the API under/1.0.Confirmed with curl:
https://eu.api.kimsufi.com/v1/dedicated/serverhttps://eu.api.kimsufi.com/1.0/dedicated/serverhttps://eu.api.ovh.com/v1/dedicated/serverhttps://eu.api.ovh.com/1.0/dedicated/serverExpected Behavior
The command should list dedicated servers on the Kimsufi account, the same way it works for an
ovh-euprofile.Steps To Reproduce
ovhcloud login --profile kseu # pick "Custom endpoint", enter https://eu.api.kimsufi.com/1.0/v1/-prefixed path, e.g.:Anything else?
Since this is entirely a client-side path-construction issue, it can be fixed without touching
go-ovh: wrap the API client so that outgoing paths starting with/v1/are rewritten to drop that prefix (letting them append under the endpoint's own/1.0base) whenever the active endpoint isn't one of the 3 official gateways (ovh-eu,ovh-ca,ovh-us). Happy to submit a PR with this fix if useful.Since this is entirely a client-side path-construction issue, it can be fixed without touchinggo-ovh: wrap the API client so that outgoing paths starting with/v1/are rewritten to drop that prefix (letting them append under the endpoint's own/1.0base) whenever the active endpoint isn't one of the 3 official gateways (ovh-eu,ovh-ca,ovh-us). Happy to submit a PR with this fix if useful.