CORS Issue: Custom Header Being Blocked by IC Boundary Node

Developers
1

I’m running a canister that serves XRPC endpoints. I’m trying to allow cross-origin requests that include a custom header atproto-accept-labelers.

My canister sets these CORS headers:

Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, POST
Access-Control-Allow-Headers: *

However, the OPTIONS preflight response from the boundary node shows more restrictive headers:

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

This is causing browsers to block requests with the custom header. Is there a way to override this?

For more context, I am trying to get https://bsky.app to send a request to my canister but it needs to include the atproto-accept-labelers when its connecting to my server
Any help would be great

3 Likes
2

Oh yes…if you need custom headers you may need to run a custom boundary board like we did with propyl.io.

:slightly_frowning_face:

1 Like
3

Maybe in theory when the boundary nodes are decentralized, each boundary node could have different settings?
This is kind of a big deal this doesn’t work for my project

Im not a big CORS guy, any thoughts on why the headers are limited but other CORS settings are *?

2 Likes
4

I’m not sure. I had issues with partial media files back in the day. I think this has been resolved. I know you can mess with headers in asset canisters using the json5 file.

See discussion: Boundary node http response headers - #72 by faraz.shaikh

This is what we used but it was last updated 3 years ago:

This may be the new one:

Maybe some clues as to what happens here: Code search results · GitHub

3 Likes
5

tagging @rbirkner
Saw you were in the other boundary node threads

6

Seems like it

2 Likes
7

Hey @Gekctek

Your observations are 100% correct. The HTTP gateway within the boundary nodes overrides whatever CORS headers you set in your canister. In particular, OPTIONS requests are directly handled by the HTTP gateway and never make it to the canister. Changing that would mean significantly increased latency for all OPTIONS requests.

I can check what the possibilities are and will report back!

3 Likes
8

That would be wonderful, thank you

9

@rbirkner Any update/additional thoughts?