Protocol-relative URL's (i.e. "//mydomain/path") do not work

[asilvas]

This is a non-issue for me as I am not using this feature, but wanted to make you aware since I caught it.

<script>
curl = {
   baseUrl: "//cdn1.mydomain.com/root/",  // WONT WORK
   pluginPath: "//cdn2.mydomain.com/root/curl/plugin",  // WONT WORK
   paths: {
      js: "//cdn3.mydomain.com/root/curl/plugin/js" // WONT WORK
   }
}
</script>
<script src="cdn1.mydomain.com/root/curl/curl.js"></script>

The above code will not work. I believe what it is doing is detecting a prefix of a single-forward slash "/" to detect for an absolute path, and ignoring the fact that double-forward means something entirely different.

[asilvas]

This issue is connected with Issue 11

[unscriptable]

Thanks! I caught this last night as well. Will add a test case for protocol-relative urls.

[unscriptable]

I can't seem to repro this anymore. Can you check with the latest in dev branch?

(I did make minor tweaks to the relative url checking regexp just now, but I wasn't able to repro before those changes.)

[asilvas]

Looks like it may have been due to me testing on a local file, versus serving up from a domain. Even still, "//" from a local file will not work -- I believe this to be a browser behavior, as some do not treat local files as "http". Another reason to just re-write http/https instead of protocol relative paths, for use with local tests.

Oddly I was also not able to repro the IE8 double-css issue using the "link!" plugin. You did not make any changes to avoid the double download bug, did you?

[unscriptable]

Looks like it may have been due to me testing on a local file, versus serving up from a domain. Even still, "//" from a local file will not work -- I believe this to be a browser behavior, as some do not treat local files as "http". Another reason to just re-write http/https instead of protocol relative paths, for use with local tests.

If you are referring to the "file:" protocol, there are other browser-related problems, too.

Oddly I was also not able to repro the IE8 double-css issue using the "link!" plugin. You did not make any changes to avoid the double download bug, did you?

Yes. I did! :)
See this commit: unscriptable@36ad576