{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreic4iuqotggm22c5ctzjx4cg776idqol5tur2orryajsmm47doghta",
    "uri": "at://did:plc:pgryn3ephfd2xgft23qokfzt/app.bsky.feed.post/3mowktyt6jcy2"
  },
  "path": "/t/hugging-face-spaces-proxy-suddenly-stripping-access-control-allow-credentials-header-on-options-preflight/177064#post_2",
  "publishedAt": "2026-06-23T02:36:19.000Z",
  "site": "https://discuss.huggingface.co",
  "tags": [
    "@hysts",
    "(click for more details)",
    "Gradio web components failing to load - #4 by John6666"
  ],
  "textContent": "Hmm… the symptom itself feels like an HF-side glitch, but I wonder if this series of glitches may be connected somehow​:\njust in case, @hysts\n\n* * *\n\nI cannot prove that this shares a root cause with other recent Spaces issues, so I would treat this only as a hypothesis.\n\nBut your specific CORS symptom looks suspicious in a useful way: the `OPTIONS` preflight response is not missing all CORS headers. It seems to include several CORS headers, but `Access-Control-Allow-Credentials: true` is missing even though your Express app is configured to return it.\n\nThat makes me wonder whether this particular `OPTIONS` path is being answered, normalized, cached, or rewritten before it reaches your container.\n\nThe first thing I would try to establish is:\n\n  * does `OPTIONS /user/login` show up in your container logs?\n  * if yes, does your container actually return `Access-Control-Allow-Credentials: true`?\n  * if no, Spaces Proxy / edge logic may be answering the preflight itself\n  * if yes but the browser/curl response does not receive it, something between the container and browser may be stripping or rewriting the header\n\n\n\nA direct preflight check would be useful:\n\n\n    curl -i -X OPTIONS \"https://<space-subdomain>.hf.space/user/login\" \\\n      -H \"Origin: https://<frontend-origin>\" \\\n      -H \"Access-Control-Request-Method: POST\" \\\n      -H \"Access-Control-Request-Headers: content-type\"\n\n\nFor credentialed CORS, I would expect the response to include something like:\n\n\n    Access-Control-Allow-Origin: https://<frontend-origin>\n    Access-Control-Allow-Credentials: true\n\n\nIf the app logs do not show the `OPTIONS` request, or if the app returns `Access-Control-Allow-Credentials: true` but the browser/curl response does not contain it, then this is probably not just an Express middleware issue.\n\nI also noticed several nearby Spaces reports that may fit the same broad class of “app/build/container is healthy, but HF-side state, active deployment, route binding, service metadata, or proxy path is inconsistent.” I am not saying they are definitely the same bug, but the pattern seems worth checking.\n\nLonger evidence map / possible HF-side consistency issue (click for more details)\n\n### Small update:\n\nThis related Web Component reply may be relevant: Gradio web components failing to load - #4 by John6666\n\nThe key clue is that the issue may not be limited to `by-subdomain`. Even the explicit `space=\"<owner>/<space_name>\"` form reportedly generated:\n\n\n    https://.hf.space/config\n\n\nThat looks like a missing resolved Space host, not a user app/runtime problem.\n\nI still would not claim the same root cause, but it fits the same broad pattern: the direct app/runtime may be fine, while a browser-facing Spaces integration path is inconsistent.\n\nFor Web Components, that suspicious path is roughly:\n\n\n    owner/name or subdomain\n      -> resolved Space host\n      -> /config\n\n\nFor this CORS issue, it may be:\n\n\n    OPTIONS preflight\n      -> Spaces Proxy / edge / active service binding\n      -> CORS headers\n\n\nSo this may be worth checking as part of the same Space identity / host resolution / active service binding layer, rather than only as an app-side CORS middleware issue.",
  "title": "Hugging Face Spaces proxy suddenly stripping Access-Control-Allow-Credentials header on OPTIONS preflight?"
}