Creating a Website Chat Widget with Gradio Part IV

Hi. Short version: I think this is probably a bug , and probably not something caused by you or your Space:

---

The most useful way to frame this is probably:

Direct/canonical paths work, but the browser-facing Gradio Web Component / Space identity / host / config-resolution path fails.

So I would not start by changing your Python code, model code, or Gradio layout. Your checks already point away from “the Space app itself is broken” and toward something in the path used by the Web Component to resolve/load the Space.

The strongest clues are:

Check	Result	What it suggests
Direct Space URL	works	the Space runtime is serving
Direct https://<space-subdomain>.hf.space/config	works	the Gradio app can expose its config from its own host
iframe embed	works	normal browser embedding of the Space works
https://huggingface.co/api/spaces/<owner>/<space_name>	works	the canonical Space repo-id API path works
<gradio-app src="https://<space-subdomain>.hf.space">	fails	Web Component + subdomain path fails
<gradio-app space="<owner>/<space_name>">	fails	Web Component + owner/name → host/config path also fails
https://huggingface.co/api/spaces/by-subdomain/<space-subdomain>	fails	the subdomain → Space identity lookup path is suspicious

That combination is hard to explain as a bug inside the user Space runtime.

The closest current GitHub issue I found is this one:

• gradio-app/gradio#13554 — Web components fail to load due to error in /api/spaces/by-subdomain/

I would not claim that this proves the exact same internal root cause, but the public symptom is extremely close: same by-subdomain endpoint, same encoded-slash style error, and the same split between src= and space= failure modes.

Why I think this points away from your Space app (click for more details) Closest issue: gradio-app/gradio#13554 (click for more details) Why src= and space= may be failing differently (click for more details)

Related, but I would not merge them as the same bug

The chat-widget/CORS thread you linked also looks relevant as context:

• Creating a Website Chat Widget with Gradio Part IV

There is also this nearby thread:

• Hugging Face Spaces proxy suddenly stripping Access-Control-Allow-Credentials header on OPTIONS preflight?

I would not say these prove the same root cause. They are different surface symptoms:

Thread	Surface symptom
this thread	Web Component fails; by-subdomain returns bad repo-name / encoded-slash error; space= can lead into bad config/CORS/retry behavior
chat-widget thread	@gradio/client call from an external site fails around credentialed CORS
Spaces proxy thread	OPTIONS preflight appears to miss Access-Control-Allow-Credentials

But they are useful context because the diagnostic shape is similar:

the app/container may be healthy, while an external browser-facing integration path fails before useful app logic runs.

For CORS specifically, MDN’s general rule is that credentialed cross-origin requests need Access-Control-Allow-Credentials: true in the relevant server response. See MDN: Access-Control-Allow-Credentials and MDN: Reason: expected true in CORS header Access-Control-Allow-Credentials.

That matters for the chat-widget case, but I would keep it secondary here. In this thread, the cleanest signal is still the by-subdomain / Web Component / host-config-resolution failure.

What I would attach to the GitHub issue or to a follow-up here

The most helpful next step is probably not “try random fixes”, but to make the reproduction mechanically clear and attach it to gradio-app/gradio#13554, or at least cross-link this forum thread from there.

Something like this would be very useful:

I may be seeing the same Web Component / Space resolution issue.

Space repo:
<owner>/<space_name>

Direct Space URL:
https://<space-subdomain>.hf.space/

Space visibility:
public / protected / private

Gradio SDK version in the Space:
...

Web Component JS version:
...

Browser / OS:
...

Direct checks:
- https://<space-subdomain>.hf.space/ => works / fails
- https://<space-subdomain>.hf.space/config => works / fails
- https://huggingface.co/api/spaces/<owner>/<space_name> => works / fails
- https://huggingface.co/api/spaces/by-subdomain/<space-subdomain> => works / fails

Embed checks:
- iframe => works / fails
- <gradio-app src="https://<space-subdomain>.hf.space"></gradio-app> => works / fails
- <gradio-app space="<owner>/<space_name>"></gradio-app> => works / fails

First failing request in DevTools Network:
...

HTTP status:
...

Response body:
...

Important response headers, if present:
- x-request-id:
- x-error-message:
- x-cache:
- via:
- cloudfront / cf / cache-related headers:

Notes:
- whether it started around June 22
- whether it reproduces with a brand-new minimal Space
- whether it reproduces in another browser
- whether the same page works with iframe

The key thing is to show the split:

direct/canonical paths work
derived/browser-facing Web Component paths fail

That is the part that makes this look platform/component-side rather than app-code-side.

Small test matrix I would use (click for more details)

What I would not try first

I would not start with:

• rewriting the Gradio app
• changing the model code
• changing the Blocks/Interface structure
• treating this as an app startup problem
• broadly weakening CORS
• assuming strict_cors=False is the fix

strict_cors=False can be relevant in a different situation, especially local/null-origin Web Component testing. Gradio’s docs describe strict_cors as a localhost/null-origin protection knob, and the Gradio 5 migration note mentions local-file Web Component testing as the case where disabling it may be needed. See:

• Gradio Blocks docs: strict_cors
• Migrating to Gradio 5 — CORS / strict_cors note
• Gradio security advisory: CORS origin validation accepts the null origin

That does not look like the first fix for this specific report, because this is a hosted HF Space where direct access, direct /config, and iframe have already been reported as working.

Temporary workaround

If this is blocking a real page, I would use iframe temporarily.

That is not a root fix for the Web Component bug, but iframe embedding is an official HF Space embed path, and it avoids some of the extra Web Component-specific Space lookup/config behavior.

<iframe
  src="https://<space-subdomain>.hf.space"
  width="850"
  height="450"
  style="border:0;">
</iframe>

Then, once the Web Component issue is fixed, it should be reasonable to switch back to the documented Web Component form:

<script
  type="module"
  src="https://gradio.s3-us-west-2.amazonaws.com/<GRADIO_VERSION>/gradio.js">
</script>

<gradio-app src="https://<space-subdomain>.hf.space"></gradio-app>

or:

<script
  type="module"
  src="https://gradio.s3-us-west-2.amazonaws.com/<GRADIO_VERSION>/gradio.js">
</script>

<gradio-app space="<owner>/<space_name>"></gradio-app>

Short version

I would treat this as a likely Web Component / HF Space identity-resolution / host/config-resolution bug until proven otherwise.

The strongest next action is probably to add your reproduction matrix to:

• gradio-app/gradio#13554

especially because your tests already show the important split:

works:
- direct Space
- direct /config
- iframe
- canonical /api/spaces/<owner>/<space_name>

fails:
- Web Component src=
- Web Component space=
- /api/spaces/by-subdomain/<space-subdomain>

That is the useful signal for maintainers and for anyone else trying to debug the same failure later.