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

Hmm… the symptom itself feels like an HF-side glitch, but I wonder if this series of glitches may be connected somehow​: just in case, @hysts

I cannot prove that this shares a root cause with other recent Spaces issues, so I would treat this only as a hypothesis.

But 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.

That makes me wonder whether this particular OPTIONS path is being answered, normalized, cached, or rewritten before it reaches your container.

The first thing I would try to establish is:

• does OPTIONS /user/login show up in your container logs?
• if yes, does your container actually return Access-Control-Allow-Credentials: true?
• if no, Spaces Proxy / edge logic may be answering the preflight itself
• if yes but the browser/curl response does not receive it, something between the container and browser may be stripping or rewriting the header

A direct preflight check would be useful:

curl -i -X OPTIONS "https://<space-subdomain>.hf.space/user/login" \
  -H "Origin: https://<frontend-origin>" \
  -H "Access-Control-Request-Method: POST" \
  -H "Access-Control-Request-Headers: content-type"

For credentialed CORS, I would expect the response to include something like:

Access-Control-Allow-Origin: https://<frontend-origin>
Access-Control-Allow-Credentials: true

If 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.

I 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.

Longer evidence map / possible HF-side consistency issue (click for more details)

Small update:

This related Web Component reply may be relevant: Gradio web components failing to load - #4 by John6666

The key clue is that the issue may not be limited to by-subdomain. Even the explicit space="<owner>/<space_name>" form reportedly generated:

https://.hf.space/config

That looks like a missing resolved Space host, not a user app/runtime problem.

I 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.

For Web Components, that suspicious path is roughly:

owner/name or subdomain
  -> resolved Space host
  -> /config

For this CORS issue, it may be:

OPTIONS preflight
  -> Spaces Proxy / edge / active service binding
  -> CORS headers

So 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.