Support for AutoHttps

[asilvas]

It would be very useful for the loader to automatically rewrite all http uri's to be https when executing under an https application. Optionally, you could add a "AutoHttps" setting to the config (default: true) if you prefer, but for any real-world use you always use https requests for https applications. Naturally, it if not running under an https app, there is no difference, requests continue through http.

This simplifies complex applications from having to remember to support both cases for every dependency. There are some cases where the caller may want to control both their http and https url's, which will also work, as you do never rewrite already https uri's even on an http application.

[unscriptable]

Hm. If all of your urls start with // instead of http:// or https://, they should adopt the protocol of the current document. Is that an option?

[asilvas]

It is an option, however, as with most any "feature", there are niche case issues in some browsers. The only bug I am aware of (would not be surprised if there were others), is that IE7/8 will download the resource twice if "//path" is utilized for link/stylesheets only. It'd be a nice add if it could be done with few bytes -- removes concern over silly issues like this.

[asilvas]

Here's the reference to what I was talking about: http://www.stevesouders.com/blog/2010/02/10/5a-missing-schema-double-download/

[unscriptable]

Thanks for that link!

Since the bug only affects link elements in IE7/8, I'd like to treat this as a bug in the link! and css! plugins and call it "done".

However, you're concerned about wrangling dozens of devs who may or may not understand that they should be using protocol-relative urls. Hm...

Let me think about this one a bit more.

[asilvas]

I thought the same, it could be rolled into the plugins themselves. My only reservation was that than you'd have the same code in multiple places, and may not be any savings. Anyway, not a big deal, as this issue is not currently holding me back.

[asilvas]

This issue is connected with Issue 13

[asilvas]

This was resolved indirectly by providing support for relative domain ("//domain") paths with Issue 13. I'll go ahead and close this issue for now, just keep in mind that one thing relative domain paths do not support is for local domain-less testing, for which there are at least workarounds for.