music-visualizer | web audio api to create an audio visualizer | Audio Utils library

Short answer: The maintainers of the service sending the 302 response to your request should update their backend config such that it adds the Access-Control-Allow-Origin header to 302 responses (and any other 3xx redirect responses) — not just to 200 OK responses.

If you can’t get them to do that, then basically you only have exactly two other options:

1. Change your frontend code to make the request through a CORS proxy; or else
2. Don’t make the request from your frontend code at all, but instead do it completely from your backend server-side code (where the same-origin policy doesn’t apply).

Explanation

Here’s what happens:

1. Your frontend code makes a request to a https://rss.art19.com/episodes/….mp3 URL.

2. The https://rss.art19.com server replies to with a 302 redirect response that has a Location: https://content.production.cdn.art19.com/…episodes/….mp3 header.

3. The browser receives that 302 response and checks the response headers to see if there’s an Access-Control-Allow-Origin header. If there isn’t, the browser blocks your code from accessing the response from the https://content.production.cdn.art19.com/….mp3 redirect URL. Instead the browser will stop and throw an exception.

You can sometimes fix this problem by taking the redirect URL and using it as the request URL in your frontend code. For example, rather than using https://rss.art19.com/episodes/….mp3 in your code, use https://content.production.cdn.art19.com/…episodes/….mp3 — since the 200 OK response from that URL does include the Access-Control-Allow-Origin header).

But in many or most cases in practice, that strategy won’t work — because it’s not feasible to preemptively identify what the redirect URL will be.

Note that, by design, browsers intentionally don’t expose redirect URLs to frontend code. So it’s impossible from frontend code to programatically get a redirect URL and do another request with it.