I have been looking at the html5 boilerplate and noticed that the jquery include url starts with a double slash. The url is //ajax.googleapis.com/ajax/libs/jquery/1.5.1/jquery.min.js
Why is the http: missing?
I hate answering with a link but this explains it - http://paulirish.com/2010/the-protocol-relative-url/
Using a protocol relative URL like "//mydomain/myresource" will ensure that the content will be served via the same scheme as the hosting page. It can make testing a bit more awkward if you ever use FILE:// and then some remote locations as they will obviously resolve back to FILE. Never the less it does resolve the mixed insecure/secure content messages you can cause by not using it.
So that if the .html is accessed via HTTPS; the page will not have any unsecured script.
Related
I'm having the SSL warning messages all over my website after switching to SSL for several assets:
Mixed Content: The page at 'https://example.com' was loaded over HTTPS,
but requested an insecure script 'http://example.com/script.js'. This
request has been blocked; the content must be served over HTTPS.
I checked the page source, every single script/css is requested over https.
I even checked the dynamically created html by using the code inspector.
I disabled Javascript in case a script was loading these assets dynamically.
None of these things showed a single http:// request. I'm out of ideas to try and find what is causing this. Any ideas or suggestions?
When seeing a mixed-content message about a http://example.com/script.js (non-https) URL that doesn’t actually appear anywhere in your sources, the basic strategy to follow is:
Replace the http in the URL with https and put that into the address bar in your browser: https://example.com/script.js
If your browser redirects from that https://example.com/script.js URL back to (non-https) http://example.com/script.js, then you’ve found the cause: example.com/script.js isn’t actually available from an https URL, and ends up getting served from a http URL even though your source is requesting the https URL.
My 2 cents regarding this issue.
I have a project hosted on one domain that works flawlessly.
I need to make it international so I am cloning the master branch to a new branch, making some necessary text changes and deploying new site (new domain) with code from the new branch.
Everything works fine, except 1 ajax call (api route) that gets blocked due to Mixed content.
First things first, I checked these 3 things:
I check in the Network tab in dev tools and it is actually loaded through https.
I open the file directly in browser and it is https.
I try to open it as http:// and it automatically redirects to https://
This is very strange because the 2 domains are both using Cloudflare and their backend setup is identical, the code is the same (only text changes for the new one) yet for the new setup there is console error for 1 specific api route, an all others (some 20+ ajax requests across the page) work just fine. They are even using the same function to make the Ajax request, so it is definitely not a configuration error.
After doing some investigation I found out the issue:
The call that was 'buggy' was ending in /. For example, all other calls were made to:
https://example.com/api/posts
https://example.com/api/users
And this particular one was making requests to
https://example.com/api/todos/
The slash at the end was making it fail with mixed content issue. I am not sure why this is causing issue and how it isn't an issue on the original site (since there the same ajax call works just fine), but it definitely fixed my issue.
If I figure out what caused the / to fail so miserably, I will post an update.
I went to Twitter's resource page here (https://twitter.com/about/resources/tweetbutton) and got the following code:
Tweet<script type="text/javascript" src="//platform.twitter.com/widgets.js"></script>
When I put this in my Wordpress template, I don't get the Twitter button -- I just get the text "Tweet". However, when I change the src for widgets.js to include https:// or http:// at the beginning it works.
Could it be that it's just an error that they forgot the protocol? Also, do you think it is better to use https (for consistency with the share link) versus http, or does it not matter?
Thanks for your suggestions.
The URL "//example.com/script.js" tells the browser to open the URL using the protocol of the current page, which is likely to be "file://" if your browser opened an html file on your own machine. Of course, you don't have a file called "file://example.com/script.js" on your computer.
In the past, urls for embedded widgets used to include the protocol (http or https), but a site visitor would receive warnings whenever a secure page loaded a script from an insecure page, and sometimes even vice versa. Now, widgets from Twitter, Google Analytics, and other sites no longer specify the protocol so that the same embed code can work on any page on the internet. The downside is that this does not work when you embed such a widget into a file and view it on your own browser by double-clicking it!
I am getting the security alert: "You are about to be directed to a connection that is not secure. the information you are sending to the current site might be transmitted to a non-secure site. Do you wish to continue?" when I try to login as a customer on my clients oscommerce website. I noticed the link in the status bar goes from a https prefix to a nonsecure http prefix. The site has a SSL certificate, so how do I ensure the entire store portion of the site directs to the secured site?
It is likely that some parts of the page, most often images or scripts, are loaded non-secure. You'll need to go through them in the browser's "view page source" view one by one and eliminate the reason (most often, a configuration setting pointing to http://).
Some external tools like Google Analytics that you may be embedding on your site can be included through https://, some don't. In that case, you may have to remove those tools from your secure site.
If you can't switch all the settings, try using relative paths
<img src="/images/shop/xyz.gif">
but the first thing is to identify the non-secure elements using the source code view of your browser.
An immediate redirection from a https:// page to a http:/ one would not result in a warning as you describe. Can you specify what's up with that?
Use Fiddler and browse your site, in the listing it should become evident what is using HTTP and HTTPS.
Ensure that the following are included over https:
css files
js files
embedded media (images, videos)
If you're confident none of your own stuff is included over http, check things like tracking pixels and other third-party gadgets.
Edit: Now that you've linked your page, I see that your <base> tag is the problem:
<base href="http://balancedecosolutions.com/products//catalog/">
Change to:
<base href="https://balancedecosolutions.com/products//catalog/">
If the suggestion from Pekka doesn't suit your needs you can try using relative links based on the schema (http or https):
e.g.,
I am a 100% valid link!
The only problem with this technique is that it doesn't work with CSS files in all browsers; though it does work within Javascript and inline CSS. (I could be wrong here; anyone want to check?).
e.g., the following :
<link rel="stylesheet" href="/css/mycss.css" />
<!-- mycss.css contents: -->
...
body{
background-image:url(//static.example.com/background.png);
}
...
...might fail.
A simple Find/Replace on your source code could be easy.
It sounds to me like the HTML form you are submitting is hardcoded to post to a non-secure page.
I'm sure i've seen a feature in apache that can rewrite urls so you can point domain2.com at domain1.com and it rewrites everything domain1.com to domain2.com on the fly.
is there a similar thing for https?
In apache, if i go to https://example.com, the page itself is over https, but all images/links are http://. Is there way to auto rewrite the html so its all https://?
(it's running zen cart by the way)
Try this:
Using a protocol-independent absolute
path:
<img src="//domain.com/img/logo.png"/>
If the browser is viewing an page in
SSL through HTTPS, then it'll request
that asset with the https protocol,
otherwise it'll request it with HTTP.
This prevents that awful "This Page
Contains Both Secure and Non-Secure
Items" error message in IE, keeping
all your asset requests within the
same protocol.
Unless you use absolute URLs everyhwere, this should work "automagically". So you only need to check two things:
use relative URLs to point to resources on your own server and
make sure you're not using <base href="http://something">
You can just link to /path/to/page.html instead of http://example.com/path/to/page.html. That way, if it's HTTP it'll stay HTTP, and if it's HTTPS it'll stay HTTPS.
If Zen Cart is adding the domain to all links, though, you'll need to edit the software.
The apache module you referenced is called mod_rewrite, and yes it can handle what you are asking for, although I agree with the above answers that using a protocol independent path is the best solution.
I am seeing the "This Page contains both secure and nonsecure items." message when viewing a page on my site from with IE 6. This does not appear in both IE 7 or Firefox. I have done some research and it appears that the problem has to do with links to HTTP:// rather than HTTPS://
Would the fix just be to view the page source and find everywhere there is an HTTP:// src and change it? I believe they are being generated from JavaScript.
Thanks Nick
Yes, you need to make sure that scripts and images are referenced via HTTPS, if the page is referenced by HTTPS.
Alternatively, try using relative URLs, so that your page can be either HTTP or HTTPS without requiring the html to change.
Are you running prototype.js?
There's a line in there to detect when the page has loaded which calls \: as a src=
Replace this src with a js file on your system. It can be blank.
SO the problem was that a 3rd party control was creating an element with and attribute src="about:blank". In IE6 this src is not trusted. The resolution for me was to create a blank.htm file. This file contained nothing but an tag.
I then set the
This fixed the issue. From what I have read, this is not a problem in newer versions of IE.