Closed ewired closed 2 years ago
Hello @ewired,
the OPTIONS response is not supplying any Access-Control-Allow-Origin header
Webdis does send Access-Control-Allow-Origin
in its response to an OPTIONS
request. The code for it is here, and this is easy to verify with curl
:
$ curl -v -X OPTIONS http://127.0.0.1:7379/
* Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to 127.0.0.1 (127.0.0.1) port 7379 (#0)
> OPTIONS / HTTP/1.1
> Host: 127.0.0.1:7379
> User-Agent: curl/7.64.1
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: Webdis
< Allow: GET,POST,PUT,OPTIONS
< Access-Control-Allow-Methods: GET,POST,PUT,OPTIONS
< Access-Control-Allow-Origin: *
< Access-Control-Allow-Headers: X-Requested-With, Content-Type, Authorization
< Connection: Keep-Alive
< Content-Type: text/html
< Content-Length: 0
<
* Connection #0 to host 127.0.0.1 left intact
* Closing connection 0
OK, it looks like fly.io HTTP handler is messing with OPTIONS request. I found where Firefox can generate a cURL command replicating the request and found that it is working when I run the container locally, but not on the Fly deployment. Thanks for checking it out.
Firefox sends a "pre-flight" OPTIONS request to check for CORS headers without sending authorization. I currently can't send authorization to a Webdis server from a userscript on a page because no-cors requests omit the Authorization header. CORS-enabled requests in
fetch
are failing because the OPTIONS response is not supplying any Access-Control-Allow-Origin header, so Firefox does not allow the subsequent GET request.