Protocol-Relative URLs to Fix Mixed-Content Warnings
1–10 of 26 posts
Re: Protocol-Relative URLs to Fix Mixed-Content Warnings
#2Third post from series:
http://autoref.com/blog/2012/09/08/the-tech-behind-autoref-p...
Full disclosure (bizdev at autoref)
Re: Protocol-Relative URLs to Fix Mixed-Content Warnings
#3The website http://www.htmlshell.com/ uses this technique when linking to a CDN jQuery. One problem, it doesn't seem to work for me when I'm developing locally, I get the error that '$' is not defined, so jQuery didn't load. Does it matter for local vs. server development?
Re: Protocol-Relative URLs to Fix Mixed-Content Warnings
#4...or you could request all your resources over SSL.
Re: Protocol-Relative URLs to Fix Mixed-Content Warnings
#5The website http://www.htmlshell.com/ uses this technique when linking to a CDN jQuery. One problem, it doesn't seem to work for me when I'm developing locally, I get the error that '$' is not defined, so jQuery didn't load. Does it matter for local vs. server development?
If you're using local files directly, // will resolve to file://, and not work as you'd expect. It'll work if you use a local web server instead, of course.
Re: Protocol-Relative URLs to Fix Mixed-Content Warnings
#6The website http://www.htmlshell.com/ uses this technique when linking to a CDN jQuery. One problem, it doesn't seem to work for me when I'm developing locally, I get the error that '$' is not defined, so jQuery didn't load. Does it matter for local vs. server development?
[deleted]
Re: Protocol-Relative URLs to Fix Mixed-Content Warnings
#7I thought the Chrome browser had recently started to block insecure content loaded from https pages; it does for me and I don't remember changing some related settings recently. Anyway yeah, it's very sane advice.
Re: Protocol-Relative URLs to Fix Mixed-Content Warnings
#8This isn't as simple as it sounds, particularly if you have something like an Atom feed. Putting an IMG SRC pointing at //example.com/foo.jpg in the HTML served as a regular web page will work fine for nearly everyone. However, putting that same construct in your feed will cause a nontrivial number of people to "GET //example.com/foo.jpg" from your web server. It's irritating.
If you then change your feed to hard-code "http://example.com/... in IMGs and such, you've just created the mixed-content hole when someone reads your feed over https. So, then you really have to have a second instance of the feed with nearly-identical URLs but with https protocols.
Why not serve https to everyone? Some places block it. They tend to be oppressive regimes, but that's the way it is. They can get to you on port 80 but not port 443.
I had to go to a hybrid scheme. Web pages get //host/path, http fetches of my Atom feed get http://host/path, and https fetches of the Atom feed get https://host/path.
Even then, some browsers still don't quite work with the web site, but I'm okay with ignoring them, since they didn't send User-Agent strings and are obviously broken. Besides, there have only been two of them so far this entire week.
( Mostly recycled from a post about this not too long ago: http://rachelbythebay.com/w/2012/08/28/feed/ )
Re: Protocol-Relative URLs to Fix Mixed-Content Warnings
#9The website http://www.htmlshell.com/ uses this technique when linking to a CDN jQuery. One problem, it doesn't seem to work for me when I'm developing locally, I get the error that '$' is not defined, so jQuery didn't load. Does it matter for local vs. server development?
If you're using local files directly, // will resolve to file://, and not work as you'd expect. It'll work if you use a local web server instead, of course.
gotcha.
Re: Protocol-Relative URLs to Fix Mixed-Content Warnings
#10Unrelated to the article, but just a small bug regarding your home page: If you choose a maker/model/ZIP and hit next, then hit the back button on your computer, you come back to the home page with the maker preselected but the model as unselectable, you have to actually choose another maker then choose the original one again to be able to pick a model.