Server URL ignored in `$schema` field for default configuration

[baderj]

I'm using the default configuration

        config := huma.DefaultConfig("Example API", "1.0.0")

and changed the server url as follows

	config.Servers = []*huma.Server{
		{URL: "https://api.example.com", Description: "Root URL of the API"},
	}

This URL is correctly reflected in the generated documentation, both for the example requests and also in the $schema of the response:

However, when requesting the API, the $schema-url is build from ctx.Host() and the listening port, which in my case is localhost:8888

 curl -s "https://api.example.com/test | jq | head
{
  "$schema": "http://localhost:8888/api/v1/schemas/Test.json",
  "data": [
    ...
  ]
}

Shouldn't the $schema in the responses also use the configured server?

[danielgtaylor]

@baderj that is one approach you could use. What I ran into is that sometimes you configure multiple servers and sometimes even multiple DNS entries for the same server (without documenting it as such). The safest thing for me so far has been to use the incoming Host header in the response so that clients can use the same host they are already using to access the schemas / openapi / docs / etc.

I'm open to ideas for when it might be better to use the configured server. Also, you can of course copy and modify the transformer code and set up your own config if this doesn't work for your specific use-case!

[tomflenner]

Hello @danielgtaylor, just saw this issue.

Do you mind point to a documentation or gives a little code snippet on how edit the response with the Host header or something like that to dynamically change the URL of schema in response ?

Thanks in advance ! 🙏🏻

[leonklingele]

We've just stumbled upon this as well at work for a Huma app which is deployed to Kubernetes and proxied to through an ingress. Huma then returns {"$schema":"https://service-name.namespace.svc.cluster.local/ [..] in the response body.
Can we make Huma use the value reported in the Forwarded / X-Forwarded-Host request header instead?

[leonklingele]

For the time being, we resort to forwarding the Host header as-is.

[wolveix]

Hi! This should be fixed in our next release :)