A first xhr request to the public endpoint also completes.
A second xhr request fails with a CORS error, with detail "Cross-origin resource sharing error: missingAllowOriginHeader"
Question is what causes the CORS error, and more importantly what can be done to solve it?
It appears that only the 1st party data is received. The app manager tried with settings like "Access-Control-Allow-Origin: *' with no success.
Details from F12 on the error line show:
From the page CORS Amazon S3 | Dynatrace Help (https://www.dynatrace.com/support/help/technology-support/cloud-platforms/amazon-web-services/config...) I learned that "Unfortunately Internet Explorer 11 and Edge don't currently support the crossorigin attribute." So I checked with Firefox, and there the issue seems not to appear. (Chrome has same result as Edge)
Note: The Cluster Activate URL is set to a public URL (eg. cag.foobar.net:443), serviced by a load-balancer and forwarded to two CAGs (in DMZ).
Solved! Go to Solution.
Noteworthy to mention is that with Chromium browsers (Edge, Chrome) this error is noticed.
But not with Firefox or IE.
From an internal system with Chrome it works without errors, but the 3rd party objects are not reachable there.
As it turns out F5 LTM loadbalancer did not change/removed the headers in http
F5 (Big-IP) ASM (Application Security Manager), a web application firewall (WAF)
however ASM can, and does. With ASM temporary disabled on the AG traffic, it works.
Instead of writing an iRule in ASM, the admin increased the maximum URL length from the default 2048 bytes to 5000 bytes first. As it appears the beacon URLs can be longer than 2K.
Support confirmed that on the /jstag and /bf endpoints, the Access-Control-Allow-Origin header is present if its a valid request to it.
This actually applies also to receiving Synthetic monitoring data in Managed.
Configuring the maximum allowed URL length for an HTTP request (f5.com)