# Gradio web components failing to load

> Source: <https://discuss.huggingface.co/t/gradio-web-components-failing-to-load/177067#post_7>
> Published: 2026-06-23 07:39:54+00:00

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.