"//..." in <script> tag is interpreted as "file://"


I’m trying to use soundcloud sdk in my Electron app as below.

<script src="http://connect.soundcloud.com/sdk-2.0.0.js"></script>

But it failed because "//..." in <script> tag in sdk-2.0.0.js is interpreted as file:// and DevTools said

GET file://connect.soundcloud.com/audiomanager/audiomanager.js net::ERR_FILE_NOT_FOUND

Is there any way to use sdk-2.0.0.js properly?


How about downloading the file and including it locally?


I think it’s bad way because I don’t know when sdk-2.0.0.js is updated.


Why not just set the protocol explicitly?

<script src=https://connect.soundcloud.com/sdk-2.0.0.js>

By not setting it you request the URL using the current protocol which will be file if you used mainWindow.loadUrl('file:///index.html') to load your application.


Did you find a solution to this? I’m looking for the same thing. I’m using a library that has // references that are interpreted by Electron as file: protocols. I’m trying to find a way to intercept this (possibly using protocol module) and rewrite it as http: but I’m not entirely sure how to do it. If I attempt to intercept it using interceptFileProtocol its expecting a file in the callback, not an http request. I guess I COULD make it programmatically download the file and return that, but then I’d need to manage the files too. Thats not the optimal solution in my opinion


Just a stab in the dark: Is it possible to fiddle with base URL to make it work better? Of course, that changes the meaning of all relative links.


The additional locations that the library references aren’t local. For instance, one of them is //dev.virtualearth.net. Would setting base still work in that situation? What would it be set to? Just “http:” and then use file:// references for everything else instead of relative path?


I hope it would work like this, yes. Maybe you need some actual site, instead of just http:. So for example, if base URL was http://www.example.com/ then any local link to /foo would resolve to http://www.example.com/foo whereas any local link to //another-example.org/bar would resolve to http://another-example.org/bar.

If the base URL starts with https then relative URLs starting // will automatically resolve to https and not http.

(Because your base URL started with file, then the relative URLs starting // automatically resolved to file and not http.)


Hi, is there any news on this issue? I’m suffering from the same problem when using the fantastic Cesium library with electron. Cesium tries to connect to remote imagery services, e.g. using a "//dev.virtualearth.net/REST/..." address.
– Norman


If anyone is facing similar problems using Cesium with electron, here’s some more advice: http://stackoverflow.com/questions/31428956/run-cesiumjs-with-no-server-requirements. I am now using a custom configuration of Cesium Viewer instead of reconfiguring electron.


You could also do a quick find and replace in the Cesium source to modify the paths, OR, don’t use the default base layer picker within Cesium and create your own using the modified urls


Same problem. I am looking into protocol handling to somehow to forward selective file:// calls to http://. More here -> http://electron.atom.io/docs/v0.30.0/api/protocol/#protocolinterceptprotocolscheme-handler-callback

Anyone had any luck with this?


@rhysd Let me ignore for a moment, that this may indeed considered a bug in Electron. SoundCloud offers the library via https, so that’s how you should load it.

Now that SSL is encouraged for everyone and doesn’t have performance concerns, this technique is now an anti-pattern. If the asset you need is available on SSL, then always use the https:// asset.

via The Protocol-relative URL by Paul Irish


@rhysd, could you solve your problem? I’m facing the same one