CORS Issue: Custom Header Being Blocked by IC Boundary Node

Developers
21

Hey @Gekctek,

Just to make sure: do you see the same behavior both locally and on mainnet? Right now, I am not aware of any regression on mainnet (or what would have caused it), but we will of course look into it, if there is an issue.

22

Ya, i am no longer getting CORS OPTIONS preflight handled in the canister, just the default headers. So I am seeing a regression on mainnet

curl -X OPTIONS \
  -H "Access-Control-Request-Method: GET" \
  -H "Access-Control-Request-Headers: atproto-accept-labelers" \
  -v \
  https://sctyd-5qaaa-aaaag-aa5lq-cai.icp0.io/xrpc/com.atproto.server.describeServer

< HTTP/2 200
< access-control-allow-methods: HEAD, GET, POST, PUT, DELETE, PATCH
< access-control-allow-headers: user-agent, dnt, if-none-match, if-modified-since, cache-control, content-type, range, cookie, x-requested-with, x-ic-canister-id, x-oc-jwt, x-oc-api-key
< access-control-max-age: 7200
< access-control-allow-origin: *
< vary: origin, access-control-request-method, access-control-request-headers
23

This is very blocking for me
Any thoughts on an ETA or workaround

1 Like
24

Hey @Gekctek,

Sorry for the delay. Unfortunately, I have a hard time finding an issue with the gateway (that doesn’t mean there isn’t one):

In general, ic-gateway does the following: it forwards the OPTIONS request to the canister. If the canister fails to reply, ic-gateway injects the default response. If the response is partially correct, ic-gateway only injects those headers that are not correct.

I tried to bypass ic-gateway to see what the response of your canister actually is for your sample request above:

curl -X OPTIONS \
  -H "Access-Control-Request-Method: GET" \
  -H "Access-Control-Request-Headers: atproto-accept-labelers" \
  -v \
  https://sctyd-5qaaa-aaaag-aa5lq-cai.icp0.io/xrpc/com.atproto.server.describeServer

To this end, I made the same call with dfx:

dfx canister call \
    sctyd-5qaaa-aaaag-aa5lq-cai \
    http_request \
    --query \
    --network https://icp-api.io \
    --candid ./http_canister.did \
    '(
  record {
    url = "/xrpc/com.atproto.server.describeServer";
    method = "OPTIONS";
    body = blob "";
    headers = vec {
      record { "Access-Control-Request-Headers"; "atproto-accept-labelers" };
      record { "Access-Control-Request-Method"; "GET" };
    };
    certificate_version = null;
  },
)'

And all I got as a response was a 404:

(
  record {
    body = blob "";
    headers = vec {};
    upgrade = null;
    status_code = 404 : nat16;
  },
)

In that case, it is normal behavior that ic-gateway injects its own preflight response.

Maybe I made some mistake with the curl to dfx translation :grimacing: I am double-checking with the expert, just to make sure.

1 Like
25

Yep, Im not sure where I screwed up, but I did

There is a bug in my CORS preflight detection, so it wasn’t handling it properly and thus the 404

Thank you for looking into it
I confirmed its working on mainnet