CORS is not respecting Access-Control-Allow-Origin header?
Reported by
trusktr@gmail.com,
Dec 29 2017
|
||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; CrOS x86_64 9901.77.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.97 Safari/537.36 Platform: 9901.77.0 (Official Build) stable-channel caroline, Google_Caroline.7820.329.0, SAMSUNG-CAROLINE Steps to reproduce the problem: 1. Open https://trusktr.io/UnionMystica.mp3 in your browser and note that the header access-control-allow-origin is set to "*". 2. Open https://s.codepen.io/trusktr/debug/EoVGge which tries to use that audio files to animate a visual based on the audio data. 3. In the console you will see that the audio is blocked due to CORS. What is the expected behavior? The access-control header is there, so the page should be able to access the audio data. What went wrong? The page can not access the audio data. Did this work before? N/A Does this work in other browsers? N/A Chrome version: 62.0.3202.97 Channel: stable OS Version: 9901.77.0 Flash Version: Am I doing something wrong? Or is there a bug?
,
Dec 29 2017
,
Dec 30 2017
The `<audio>` element here needs a `crossOrigin` attribute or either `true` or "anonymous". When that is added, the code appears to works as expected.
,
Dec 31 2017
You're right, it worked. That's seems redundant. Why aren't headers enough?
,
Jan 2 2018
the browser checks cors during a preflight request which isn't for free (performance wise), so the default is to skip it
,
Jan 2 2018
,
Jan 2 2018
I'm not sure I understand: obviously if the URL is not from my domain it should just check CORS headers? Can't we assume that if someone or something puts a resource from a different domain that CORS needs to be checked? |
||||
►
Sign in to add a comment |
||||
Comment 1 by trusktr@gmail.com
, Dec 29 2017