Access to XMLHttpRequest has been blocked by CORS policy: Request header field traceparent is not allowed by Access-Control-Allow-Headers in preflight response

For engineers Troubleshooting
1

Access to XMLHttpRequest at ‘https://*.mini.snplow.net’ from [Site Here] has been blocked by CORS policy: Request header field traceparent is not allowed by Access-Control-Allow-Headers in preflight response.

Is it possible to have the Snowplow server accept preflight requests (OPTIONS requests)?

This is needed to so we can send events to Snowplow with request header values that are automatically added from having Datadog APM traces correlated in Datadog RUM.

1 Like
2

The collector will accept preflight requests without too many issues but it does restrict the headers for OPTIONS specifically. Do you need the trace on both the OPTIONS and POST or is POST sufficient?

3

Gotcha! It needs to be on OPTIONS!

From the Datadog RUM docs:

These HTTP headers are not CORS-safelisted, so you need to configure Access-Control-Allow-Headers on your server handling requests that the SDK is set up to monitor. The server must also accept preflight requests (OPTIONS requests), which are made by the SDK prior to every request.

4

Unfortunately right now it looks like they are hardcoded in the collector. I’ll chat with the team and see if it’s possible to instead make the allowed headers a customisable variable.

1 Like
5

Thank you, that would be really helpful!

6

I’ve opened a PR to add this functionality in.

3 Likes
7

Any updates on merging the PR yet?

8

There’s some discussion internally at the moment around what the best approach to this is.

For clarity - do you want these traces to show up in Datadog / RUM and if so are you using corresponding backend traces or would you prefer these didn’t show up in RUM at all (in which case getting Datadog to only selectively send the header is a better solution).

9

If you don’t actually care about measuring the performance of the Snowplow requests, it’s good to note also that the regular expression value for configuring allowedTracingUrls in DataDog evaluates the pattern against the entire URL.

So if you think your configuration excludes requests to your collector but are still encountering this, double check if you’re using eventMethod: 'get' or not – this will include the current/previous page URL as query parameters and might accidentally match the pattern by making DataDog think it’s a request to the same domain as the page instead of your collector. Switching to POST to remove the query parameters from the request URL, or making your pattern stricter to only evaluate the hostname might be the issue.