Gradio web components failing to load

Gradio web components are failing to load on Hugging Face Spaces due to a host resolution issue, generating malformed URLs like 'https://.hf.space/config' instead of valid Space subdomains. The problem appears to be a browser-facing integration path failure rather than a user app runtime bug, potentially linked to broader Spaces proxy or CORS inconsistencies.

Thanks. I see. If it happens with that method too, this may connect to something beyond just Gradio itself https://discuss.huggingface.co/t/hugging-face-spaces-proxy-suddenly-stripping-access-control-allow-credentials-header-on-options-preflight/177064 : The https://.hf.space/config part changes the picture quite a bit. My previous guess was narrower: src="https://<space-subdomain .hf.space" → possibly failing through the by-subdomain lookup path But if this also happens with: <gradio-app space="<owner /<space name " </gradio-app and the component repeatedly tries to fetch: https://.hf.space/config then this looks broader than only a by-subdomain reverse-lookup problem. A literal empty-host URL like this: https://.hf.space/config suggests that the web component, or the Hugging Face Space metadata/config resolution path behind it, failed to resolve a valid .hf.space host at all. So I would update the working hypothesis to something like this: src="https://<space-subdomain .hf.space" → may fail through by-subdomain lookup space="<owner /<space name " → may fail through owner/name → resolved Space host/config lookup common layer: browser-facing Space identity/config resolution path That is hard to explain as a bug inside the user Space runtime itself. If the generated URL is literally: https://.hf.space/config then the missing value is probably the resolved Space subdomain / host, not something inside the Gradio app running in the Space. Why this seems broader than the original repo-name hypothesis The earlier repo-name hypothesis still seems useful for the by-subdomain error, especially because of the similar Gradio issue here: In that issue, this request: GET https://huggingface.co/api/spaces/by-subdomain/jglowa-ai-gov-pl returns: {"error":"Invalid repo name: jglowa/ai-gov.pl - repo name includes an url-encoded slash"} That still looks like a suspicious subdomain → repo-id lookup / validation problem. But your new result adds another layer: space="<owner /<space name " → https://.hf.space/config That means the explicit space= form does not fully avoid the failing path in your case. Instead, it seems to reach a different failure mode: the component cannot build a valid config URL. So I would now separate the possible issues like this: | Layer | Example symptom | | Repo/subdomain lookup issue | /api/spaces/by-subdomain/<space-subdomain returns Invalid repo name ... url-encoded slash | | Space host/config resolution issue | web component generates https://.hf.space/config | | Browser/proxy/CORS issue | config/preflight/browser request fails before useful app logic runs | | User app runtime issue | direct .hf.space app itself fails | Your report seems to point more toward the middle two layers than the last one. Why this may connect to the Spaces proxy / CORS thread This may be related to the other recent Spaces proxy/CORS report, although I would not claim the same root cause: The common pattern would not be: the user app crashed It would be closer to: the direct app/runtime may be healthy, but a browser-facing Spaces integration path is inconsistent Examples of those browser-facing paths: web component config fetch Space host resolution by-subdomain lookup CORS preflight Spaces proxy / edge handling active service binding metadata / route consistency The CORS thread is about a different surface area, but it has a similar diagnostic shape: the problem may be outside the user container if the browser-facing request is answered, rewritten, stripped, cached, or misrouted before it reaches the app. Here, https://.hf.space/config is similarly suspicious because it looks like the component or metadata layer lost the host before the app could even matter. Checks that may narrow it down I would try to separate these paths: curl -i https://<space-subdomain .hf.space/config curl -i https://huggingface.co/api/spaces/by-subdomain/<space-subdomain curl -i https://huggingface.co/api/spaces/<owner /<space name And compare the browser behavior of: <iframe src="https://<space-subdomain .hf.space" </iframe <gradio-app src="https://<space-subdomain .hf.space" </gradio-app <gradio-app space="<owner /<space name " </gradio-app The most useful matrix would be: | Test | Result | Direct https://<space-subdomain .hf.space | works / fails | Direct https://<space-subdomain .hf.space/config | works / fails | | iframe embed | works / fails | <gradio-app src="https://<space-subdomain .hf.space" | works / fails | <gradio-app space="<owner /<space name " | works / fails | /api/spaces/by-subdomain/<space-subdomain | works / fails | /api/spaces/<owner /<space name | works / fails | | Gradio docs site embed | works / fails | | Gradio web component JS version | 5.49.1 / other | If direct Space access works but both web component forms fail, then I would stop focusing on the Space app code and treat this as a Gradio web component / HF Space identity-resolution / config-fetch / proxy issue. Short version: your space="<owner /<space name " result makes this look less like only a repo-name-specific by-subdomain issue and more like a broader browser-facing Spaces integration problem. Especially if the web component literally requests: https://.hf.space/config then something upstream failed to resolve the Space host before the request even reached the user app.