Home
Support Forums

CORS error with background functions only

Hopefully someone can help me…

How do I make a cross-site request to a background function?

I’m getting a CORS error in the browser when I ping a Netlify function, even though my function contains the Access-Control-Allow-Origin header.

For some reason the CORS error only happens when I use a function with -background in the file name. If I remove -background from the file name (i.e. convert it to a normal function) the CORS error is fixed.

Do background functions ignore the Access-Control-Allow-Origin header?

I’ve been stuck on this for hours. :man_facepalming:

Thanks in advance.

return {
            statusCode: 202,
            body: JSON.stringify({
                data
            }),
            headers: {
                'Access-Control-Allow-Origin': 'https://example.com',
            }
        };

Update:

This might be a bug.

It can be reproduced.

Assumptions:

Steps:

  1. Call the lambda function at https://example.com from the frontend at https://otherdomain.com:
const url = `https://example.com/.netlify/functions/hello`;

await fetch(url);

Browser shows Response 200 (as expected).

  1. Now add -background to your function file name and redeploy and update the call:
const url = `https://example.com/.netlify/functions/hello-background`;

await fetch(url);

Browser says CORS error.
Postman says 202 Accepted.
Netlify Function Logs show it succeeded.

I expected…

  • I expected the browser to say 202 Accepted like Postman did, when calling a background function.
  • I expected the function would not actually be triggered if browser says CORS error (but it is triggered).

Other observations:

  • With regular functions: Setting the Access Control Allow Origin header in the function removes the CORS error from the browser (but has no impact on whether the request is accepted/rejected).
  • With background functions: CORS error shows in the browser regardless of any Access Control Allow Origin header in the function.

Is this intended behavior?

Hi, @vcamp. This isn’t a bug as this is expected behavior. I’ll do my best to explain why (and there is a solution at the end).

The background function never returns content to the browser so you will never be able to return customer headers being set inside the function invocations. You can never fix CORS headers using headers returned by background functions because the never reply directly to the browser. Because they never reply directly to the browser there is no way to include a custom header from the function itself.

The background function documentation says this:

These longer-running functions are processed as background tasks through AWS Lambda using asynchronous invocation. This means that when a function is invoked, it’s added to a queue instead of being processed immediately. There is an initial 202 success response when a function is queued.

Our systems send a 202 status and the function itself never replies to the browser.

About this:

  • I expected the function would not actually be triggered if browser says CORS error (but it is triggered).

The function invocation has no way of detecting the CORS error in the browser. It only sees the HTTP request and that queues the function invocation.

The background function cannot know about the CORS errors from the browser because there is no communication between the two.

About this:

  • With background functions: CORS error shows in the browser regardless of any Access Control Allow Origin header in the function.

The comment above assumes the headers are sent but that isn’t happening in reality. There are no custom headers being sent with a background function response because the background function never sends a response to the browser.

:smiley: BUT WAIT! THERE IS A SOLUTION! :+1: (*insert snappy Netlify advertisement song here*)

The recommended solution for this would be to proxy to the other function so the function invocation appears to be happening on the first domain from the browser’s point of view. For example, you might put this in _redirects:

https://otherdomain.com/api/background/* https://example.com/.netlify/functions/:splat 200!

If you called this URL:

  • https://otherdomain.com/api/background/example-background

with that redirect above active, it would (invisibly to the browser) proxy that request to this URL:

  • https://example.com/.netlify/functions/example-background.

This will avoid the CORS error because the domain will match in the browser but, behind the scenes at Netlify, you will still be calling the background function on the other domain.

If that doesn’t fix the issue or if there are any other questions, please let us know.

Hi @luke thank you! You helped me a lot.

What if we need to ping from a CMS domain like store.myshopify.com?

Then store.myshopify.com wouldn’t be aware of my _redirects file in https://example.com:

https://store.myshopify.com/api/background/* https://example.com/.netlify/functions/:splat 200!

I would need access to the server-side code on store.myshopify.com, right? Or am I missing something?

Hi, @vcamp. If the other domain (meaning store.myshopify.com in this example) isn’t hosted at Netlify and you want to proxy to a site at Netlify, then you need to configure the proxy at the host of that domain.

In other words, you will need to configure the proxy at the host for store.myshopify.com. I can tell you how to configure proxying at Netlify but I cannot provide technical support for Shopify. That being said, if Shopify is the other host, I found some instructions for configuring proxies with Shopify here:

1 Like

@Yesenia,

If you describe your issue, we can help you.