UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.119 Safari/537.36

Steps to reproduce the problem:
Reproducing this is a bit of an involved process, requiring

1. Having Widevine-protected, DASH-enabled video content to play
2. An endpoint that responds to Widevine requests
3. A DASH-enabled video player configured to send Widevine requests to that endpoint (I'm using Shaka)
4. Configuring the endpoint to re-direct to another server that will successfully fulfill the Widevine request

What is the expected behavior?
Given that a Widevine license is successfully acquired, I'd expect the browser to use that license to initiate playback.

What went wrong?
I'm a web developer working on a video streaming platform, and am attempting to finish off a Widevine implementation. Due to a quirk of our backend, we sometimes have to re-direct Widevine license requests to a different server. I have attempted to do this by returning a 307 response with the proper Location header. Looks like CORS issues may be preventing this solution from working, (we use values from the cookie to do some processing before sending on the request to Widevine's servers). It looks like I may have to come to terms with the fact that a redirect-based solution will not work in this case, but before I do that I'm seeing something odd in the network pane of Chrome's dev tools that leads me to believe that we're successfully delivering a license to the browser, which makes me wonder why playback doesn't happen.

I have exported the networking tab's output as an .har file which is available at https://s3-us-west-2.amazonaws.com/uplynk-tmp/localhost.har

You can see that the original requests to my Widevine endpoint go to content.uplynk.localhost/wv, and have been 307 redirected to content-dev.uplynk.localhost/wv. You can also see subsequent requests to the redirected domain successfully return a license with a 200 response.

However, there are a couple of requests that the browser apparently blocks because of CORS. A
screenshot from the network panel is available at https://s3-us-west-2.amazonaws.com/uplynk-tmp/Screen+Shot+2018-01-26+at+1.15.59+PM.png

In there, you can again see the initial requests, the redirected requests, as well as some other requests that failed. The number of failed requests correspond with the number of CORS-related errors I find in my JS console, which reads:

>>> Failed to load http://content-dev.uplynk.localhost:8000/wv: The 'Access-Control-Allow-Origin' header has a value 'http://localhost:8001' that is not equal to the supplied origin. Origin 'null' is therefore not allowed access. Have the server send the header with a valid value, or, if an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.

Given that it appears as though we're successfully delivering a license via redirects, I'm confused about why I'd be getting CORS-related errors in the console.

FWIW, when I run Chrome with --web-security-disabled and checking the service workers' "Bypass for network" box in the dev console's "Application" tab, all of the same requests/redirects happen successfully as before, minus the CORS errors in the JS console. And playback happens successfully. 

If the browser successfully acquires a license via re-directs, why won't it use that license to initiate playback? Is there just something CORS-related that I'm missing/mis-understanding?

Did this work before? No 

Does this work in other browsers? No
 The behaviour in Firefox is roughly identical to what's described in my "What went wrong" description. Other browsers are irrelevant because they do not include a Widevine CDM. I haven't yet filed a bug with Mozilla.

Chrome version: 64.0.3282.119  Channel: stable
OS Version: OS X 10.13.3
Flash Version: 

I posted this question in the Shaka team's github repo: https://github.com/google/shaka-player/issues/1256 and was encouraged to file a report with the Chromium team.