Request: Provide way to disable CORS requirement during testing

[GoogleCodeExporter]

bonus points: allow it to be disabled permanently for a specific player.

I don't understand why there is a requirement to only play from sources which 
are cors enabled - the android/ios device player will merrily play HLS content 
from any unverified source on the web. Why should a chromecast player be 
different?

Original issue reported on code.google.com by rob.jon...@gmail.com on 28 Feb 2014 at 5:59

[GoogleCodeExporter]

That is part of the HTML5 Security standards, so it doesn't apply to 
Android/iOS since they are not web-based platforms. I imagine you want that 
disabled during "development" and not "testing", since test should include 
that. Anyhow, folks set up their own proxies while doing development, etc but 
in production, you do not want to use any proxy, instead want to address the 
issue at the CDN end, etc.

Original comment by anad...@google.com on 28 Feb 2014 at 6:26

• Changed state: WontFix

[GoogleCodeExporter]

ok - I don't know my way around html5 security. 
sure - by testing, I mean development.

As to addressing things at the CDN end, you're making an assumption about how 
content is delivered. In my case, that meant updating an app which runs an 
internal web server. (VLC Streamer)

It would have been a big help to be able to turn off the cors requirement while 
doing a proof of concept - just to check that my setup was going to work. You 
allow disabling the https requirement during development (of the receiver) - 
why not the cors requirment? 

Original comment by rob.jon...@gmail.com on 28 Feb 2014 at 11:24

[GoogleCodeExporter]

Why don't you set up a simple proxy when doing your POC?

Original comment by anad...@google.com on 28 Feb 2014 at 11:44

[GoogleCodeExporter]

how would I do that? (please bear in mind that the content is on the local 
network.)

Would it be anywhere near as quick as checking the box 'disable cors for 
development' (only for non-published apps)

My point isn't that these issues are insurmountable - just that they're a pita.

Chromecast is a big deal for you - but for me (and for many other developers), 
it's a low priority additional feature for an existing app.

When I want to send content to apple airplay - it isn't much harder than saying 
'yes, please allow airplay'.

For chromecast it's a lot more complicated, and being able to turn off one of 
the complications as I get things working would make life easier. I spent a day 
battling chromecast before I managed to get any content showing. CORS was one 
of the many issues I had to deal with. 

At the point where I was refactoring my webserver code to allow me to add a 
header, I didn't know whether the content I was generating was even going to 
play on chromecast.

Original comment by rob.jon...@gmail.com on 1 Mar 2014 at 2:21

[GoogleCodeExporter]

Understand your concern and difficulty in getting CORS working but as long as 
you have access to the web server of your content, you can simply add a 
.htaccess file in the folder where you server content with the following 
directive:

Header set Access-Control-Allow-Origin "*"

then you'll get a very permissive response header like this:

Access-Control-Allow-Origin:·*(CR)(LF)

and you should have no problem with CORS from Chromecast.

Original comment by shawns...@google.com on 1 Mar 2014 at 5:09

[GoogleCodeExporter]

I have cors working - my point was that it was an annoying and unnecessary step 
that I would have preferred to postpone until after initial development.

In my case, the server was cocoahttp server - it doesn't support htaccess. It 
required me to subclass a handful of response classes to add header support. To 
test that things work on my windows server (which uses a subtly different 
version of VLC to convert to HLS, I have to pay a contractor to do the same for 
webserving through .net 
I haven't done this - so I'm proceeding somewhat blindly.

Your own documentation mentions that CORS is often the first issue that 
developers come across. Why persist in enforcing this issue when it is clearly 
unnecessary in development?

https://developers.google.com/cast/docs/player

"This is often the first issue that comes up when a developer wishes to use 
streaming content.

Many developers have found that that their servers are configured to need CORS, 
when they start to fix it, they progressivly discover that all the assets need 
CORS, you can choose to keep up with this, or not based on the configuration of 
your server(s) and CDN's. The assets that may need CORS headers include 
manifests, secondary manifests, segments, and crypto keys."

I can accept that this is needed for production - but why not make life easier 
for developers while they get started?

Original comment by rob.jon...@gmail.com on 1 Mar 2014 at 7:17