tinyhumansai/openhuman · error · anyhow::Error

HTTP {} while fetching {} — {}

Error message

HTTP {} while fetching {} — {}

What it means

`fetch_json` GETs a URL (used for OAuth discovery documents: `{issuer}/.well-known/openid-configuration` and `{issuer}/.well-known/oauth-authorization-server`) and got a non-2xx; the message embeds status, URL and body. In `fetch_authorization_server_metadata` the OIDC attempt is allowed to fail and falls back to the OAuth variant — this error only reaches you when the *last* attempt (the oauth-authorization-server document) also fails.

Source

Thrown at src/openhuman/mcp/http_client/client.rs:638

                    }
                }
                req
            }
            McpAuthConfig::QueryParam { name, value } => {
                request.query(&[(name.as_str(), value.as_str())])
            }
        }
    }

    async fn fetch_json<T>(&self, url: &str) -> anyhow::Result<T>
    where
        T: for<'de> Deserialize<'de>,
    {
        let response = self.http.get(url).send().await?;
        let status = response.status();
        let text = response.text().await?;
        if !status.is_success() {
            anyhow::bail!("HTTP {} while fetching {} — {}", status.as_u16(), url, text);
        }
        serde_json::from_str(&text).with_context(|| format!("parsing JSON from {url}"))
    }

    async fn fetch_authorization_server_metadata(
        &self,
        issuer: &str,
    ) -> anyhow::Result<AuthorizationServerMetadata> {
        let trimmed = issuer.trim_end_matches('/');
        let oidc = format!("{trimmed}/.well-known/openid-configuration");
        if let Ok(metadata) = self.fetch_json::<AuthorizationServerMetadata>(&oidc).await {
            return Ok(metadata);
        }
        let oauth = format!("{trimmed}/.well-known/oauth-authorization-server");
        self.fetch_json::<AuthorizationServerMetadata>(&oauth).await
    }

    fn validate_protocol_version(&self, version: &str) -> anyhow::Result<()> {

View on GitHub (pinned to 7491200858)

Solutions

1. Open both well-known URLs in a browser/curl and confirm one returns JSON metadata.
2. Fix the issuer/authorization URL — it must be the exact base the documents live under.
3. If the server publishes metadata at a custom path, configure that endpoint directly instead of relying on discovery.
4. If discovery genuinely is not supported, use static token auth for that server instead of OAuth.

Example fix

# diagnose with:
# curl -i https://issuer.example.com/.well-known/oauth-authorization-server
# ensure it returns 200 + JSON before configuring OAuth for that MCP server

// before OAuth config, probe discovery yourself:
// GET {issuer}/.well-known/openid-configuration
// GET {issuer}/.well-known/oauth-authorization-server
// at least one must return 200 JSON

match client.discover_metadata(issuer).await {
    Err(e) if e.to_string().contains("HTTP 404") => {
        // no discovery: fall back to static token auth for this server
    }
    other => other,
}

When it happens

Trigger: OAuth discovery against an issuer that publishes neither well-known document, publishes them at a non-standard path, requires auth for metadata, or returns 404/401/5xx; a typo'd or redirected issuer URL.

Common situations: MCP servers whose auth server is a plain OAuth2 AS without OIDC discovery; issuer URL with trailing path confusion; corporate proxies intercepting well-known endpoints; dev servers without discovery enabled.

Related errors

• Timed out waiting for browser sign-in. Try again.
• MCP events GET {} — {}
• MCP DELETE failed with {}
• MCP notification {method} failed with {} — {}
• unsupported MCP protocol version negotiated by server: {vers

AI-assisted analysis of tinyhumansai/openhuman@7491200858 (2026-08-17). Data as JSON: /api/errors/1a691992c3dee7d7. Report an issue: GitHub.