Gradio web components failing to load

Thanks. I see. If it happens with that method too, this may connect to something beyond just Gradio itself:

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.

source & further reading

discuss.huggingface.co — original article Rakarrack-0.6.1 port making progress! ( AI assisted ) Cloud Storage Poll Welcome to Haiku basic(Haiku Docs, Haiku slide and Haiku sheets)