{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreic7ee3gjwh7sbpky7e23idziawihxaagsdwclfcxrrtgjwmxojbbi",
    "uri": "at://did:plc:pgryn3ephfd2xgft23qokfzt/app.bsky.feed.post/3mpg5amnmp632"
  },
  "path": "/t/creating-a-website-chat-widget-with-gradio-part-iv/177208#post_2",
  "publishedAt": "2026-06-29T07:13:14.000Z",
  "site": "https://discuss.huggingface.co",
  "tags": [
    "gradio-app/gradio#13554 — Web components fail to load due to error in /api/spaces/by-subdomain/<subdomain>",
    "(click for more details)",
    "Creating a Website Chat Widget with Gradio Part IV",
    "Hugging Face Spaces proxy suddenly stripping Access-Control-Allow-Credentials header on OPTIONS preflight?",
    "MDN: Access-Control-Allow-Credentials",
    "MDN: Reason: expected true in CORS header Access-Control-Allow-Credentials",
    "gradio-app/gradio#13554",
    "Gradio Blocks docs: strict_cors",
    "Migrating to Gradio 5 — CORS / strict_cors note",
    "Gradio security advisory: CORS origin validation accepts the null origin",
    "@gradio"
  ],
  "textContent": "Hi. Short version: I think this **is probably a bug** , and probably not something caused by you or your Space:\n\n* * *\n\nThe most useful way to frame this is probably:\n\n> Direct/canonical paths work, but the browser-facing Gradio Web Component / Space identity / host / config-resolution path fails.\n\nSo 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.\n\nThe strongest clues are:\n\nCheck | Result | What it suggests\n---|---|---\nDirect Space URL | works | the Space runtime is serving\nDirect `https://<space-subdomain>.hf.space/config` | works | the Gradio app can expose its config from its own host\niframe embed | works | normal browser embedding of the Space works\n`https://huggingface.co/api/spaces/<owner>/<space_name>` | works | the canonical Space repo-id API path works\n`<gradio-app src=\"https://<space-subdomain>.hf.space\">` | fails | Web Component + subdomain path fails\n`<gradio-app space=\"<owner>/<space_name>\">` | fails | Web Component + owner/name → host/config path also fails\n`https://huggingface.co/api/spaces/by-subdomain/<space-subdomain>` | fails | the subdomain → Space identity lookup path is suspicious\n\nThat combination is hard to explain as a bug inside the user Space runtime.\n\nThe closest current GitHub issue I found is this one:\n\n  * gradio-app/gradio#13554 — Web components fail to load due to error in /api/spaces/by-subdomain/<subdomain>\n\n\n\nI 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.\n\nWhy 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)\n\n## Related, but I would not merge them as the same bug\n\nThe chat-widget/CORS thread you linked also looks relevant as context:\n\n  * Creating a Website Chat Widget with Gradio Part IV\n\n\n\nThere is also this nearby thread:\n\n  * Hugging Face Spaces proxy suddenly stripping Access-Control-Allow-Credentials header on OPTIONS preflight?\n\n\n\nI would **not** say these prove the same root cause. They are different surface symptoms:\n\nThread | Surface symptom\n---|---\nthis thread | Web Component fails; `by-subdomain` returns bad repo-name / encoded-slash error; `space=` can lead into bad config/CORS/retry behavior\nchat-widget thread | `@gradio/client` call from an external site fails around credentialed CORS\nSpaces proxy thread | `OPTIONS` preflight appears to miss `Access-Control-Allow-Credentials`\n\nBut they are useful context because the diagnostic shape is similar:\n\n> the app/container may be healthy, while an external browser-facing integration path fails before useful app logic runs.\n\nFor 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.\n\nThat 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.\n\n## What I would attach to the GitHub issue or to a follow-up here\n\nThe 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.\n\nSomething like this would be very useful:\n\n\n    I may be seeing the same Web Component / Space resolution issue.\n\n    Space repo:\n    <owner>/<space_name>\n\n    Direct Space URL:\n    https://<space-subdomain>.hf.space/\n\n    Space visibility:\n    public / protected / private\n\n    Gradio SDK version in the Space:\n    ...\n\n    Web Component JS version:\n    ...\n\n    Browser / OS:\n    ...\n\n    Direct checks:\n    - https://<space-subdomain>.hf.space/ => works / fails\n    - https://<space-subdomain>.hf.space/config => works / fails\n    - https://huggingface.co/api/spaces/<owner>/<space_name> => works / fails\n    - https://huggingface.co/api/spaces/by-subdomain/<space-subdomain> => works / fails\n\n    Embed checks:\n    - iframe => works / fails\n    - <gradio-app src=\"https://<space-subdomain>.hf.space\"></gradio-app> => works / fails\n    - <gradio-app space=\"<owner>/<space_name>\"></gradio-app> => works / fails\n\n    First failing request in DevTools Network:\n    ...\n\n    HTTP status:\n    ...\n\n    Response body:\n    ...\n\n    Important response headers, if present:\n    - x-request-id:\n    - x-error-message:\n    - x-cache:\n    - via:\n    - cloudfront / cf / cache-related headers:\n\n    Notes:\n    - whether it started around June 22\n    - whether it reproduces with a brand-new minimal Space\n    - whether it reproduces in another browser\n    - whether the same page works with iframe\n\n\nThe key thing is to show the split:\n\n\n    direct/canonical paths work\n    derived/browser-facing Web Component paths fail\n\n\nThat is the part that makes this look platform/component-side rather than app-code-side.\n\nSmall test matrix I would use (click for more details)\n\n## What I would _not_ try first\n\nI would not start with:\n\n  * rewriting the Gradio app\n  * changing the model code\n  * changing the Blocks/Interface structure\n  * treating this as an app startup problem\n  * broadly weakening CORS\n  * assuming `strict_cors=False` is the fix\n\n\n\n`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:\n\n  * Gradio Blocks docs: strict_cors\n  * Migrating to Gradio 5 — CORS / strict_cors note\n  * Gradio security advisory: CORS origin validation accepts the null origin\n\n\n\nThat 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.\n\n## Temporary workaround\n\nIf this is blocking a real page, I would use iframe temporarily.\n\nThat 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.\n\n\n    <iframe\n      src=\"https://<space-subdomain>.hf.space\"\n      width=\"850\"\n      height=\"450\"\n      style=\"border:0;\">\n    </iframe>\n\n\nThen, once the Web Component issue is fixed, it should be reasonable to switch back to the documented Web Component form:\n\n\n    <script\n      type=\"module\"\n      src=\"https://gradio.s3-us-west-2.amazonaws.com/<GRADIO_VERSION>/gradio.js\">\n    </script>\n\n    <gradio-app src=\"https://<space-subdomain>.hf.space\"></gradio-app>\n\n\nor:\n\n\n    <script\n      type=\"module\"\n      src=\"https://gradio.s3-us-west-2.amazonaws.com/<GRADIO_VERSION>/gradio.js\">\n    </script>\n\n    <gradio-app space=\"<owner>/<space_name>\"></gradio-app>\n\n\n## Short version\n\nI would treat this as a likely Web Component / HF Space identity-resolution / host/config-resolution bug until proven otherwise.\n\nThe strongest next action is probably to add your reproduction matrix to:\n\n  * gradio-app/gradio#13554\n\n\n\nespecially because your tests already show the important split:\n\n\n    works:\n    - direct Space\n    - direct /config\n    - iframe\n    - canonical /api/spaces/<owner>/<space_name>\n\n    fails:\n    - Web Component src=\n    - Web Component space=\n    - /api/spaces/by-subdomain/<space-subdomain>\n\n\nThat is the useful signal for maintainers and for anyone else trying to debug the same failure later.",
  "title": "Creating a Website Chat Widget with Gradio Part IV"
}