when I turned on SSL on my Drupal 7 website I've also turned on module to replace all images, styles, etc. path from
src="http://example.com/path/to/my/image.jpg" to
"//example.com/path/to/my/image.jpg".
I've noticed, that right now I have a lot of page not found (404) in my log, and they look like https://example.com/example.com/path/to/my/image/jpg.
Do You know, what can I do to prevent this 404 errors? Maybe some htaccess redirect? Do You think It's fault of old web browsers which don't support protocol-relative URL?
I had exactly the same problem and this addition to .htaccess seems to have resolved it for me:
RewriteRule ^//example.com/(.*)$ /$1 [NC,L,R=301]
My theory is that those 404 errors were the result of some poorly written bots crawling the website or some non-standard browsers that don't support protocol relative URLs. Normal browsers add the proper protocol to the URLs before accessing the server, so in theory the server shouldn't ever see such URLs in the requests.
Related
So I'm pretty familiar with html, css and java Script. And this moving company I work for wanted to know if I could fix this unsecured link in there html. I used Why no Padlock? and found that this link in the head tags is unsecure
https://www.whynopadlock.com/results/bcfb1f57-2f59-4787-8979-24beea641fe0
You can see that it's using http. Would making it https fix the issue or break the link?
Test result:
A file with an insecure url of "http://fonts.googleapis.com/css?family=Open+Sans:400,300,600,700,800&subset=latin,latin-ext" was loaded on line: 20 of your site.
This URL will need to be updated to use a secure URL for your padlock to return.
I just had a look at your test results, it basically says that you include a google fonts stylesheet. Update that <link to use https:// and you should be good.
Making it https:// will make your site inaccessible if you haven't obtain what is called SSL for your domain.
To fix that, obtain a SSL certificate for your website and the site will be served with https:// even when accessed with http://
It's my understanding that if you have an https site you want all external files - js, css, images, etc - to be https as well, lest you get warnings about having some content that isn't secure or something.
Well I just tried that out and didn't get any warnings at all.
Where do I see these warnings? Also, assuming this is true... is the opposite true? Do you risk any warnings if you include https content on an http site?
FWIW I tried this:
<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.8.3/jquery.min.js"></script>
Google has people doing this by default:
<script src="//ajax.googleapis.com/ajax/libs/jquery/1.8.3/jquery.min.js"></script>
That'll make it so it's fetched from either http or https depending on what your website is using. Of course if https on http doesn't give any warnings it seems that doing https for all js files would work just as well..
Error messages will be displayed on the user/viewer's browser.
[This site] (https://security.stackexchange.com/questions/1692/is-posting-from-http-to-https-a-bad-practice) has some explanation why there are error messages.
Assuming you are asking how google's code works, it is called a protocol-relative URL. The protocol of the linked file will inherit the protocol of the page including it.
So if your page is https then it would send for it over https.
You can use
<script src="https://ajax.googleapis.com/ajax/jquery/1.8.3/jquery.min.js"></script>
Or remove the "https:" and have the js sent over https, provided your page is https.
Just to add another thing, if you load content through http on a https webpage, then you'll get warnings, but if you do the opposite, then there wont be any, but keep in mind that https is a slower than http. So use https only on https pages.
I recently applied an SSL certificate to my domain, but I'm having problems with some of the styles when viewing my website on HTTP:// the styles are fine. But, when viewing it through HTTPS:// no styles are applied at all.
I found out what the problem was. I wasn't loading my third party styles through HTTPS. I switched to HTTPS, and all problems were solved.
You're probably using an http:// link to a stylesheet on an https:// website.
Secure websites are not allowed to mix protocols. Everything has to be embedded from a secure server. Browsers will ignore/block HTTP resources on HTTPS pages (with varying degree of strictness).
The reason for this blocking is that insecure HTTP resources like stylesheets and scripts could still be modified by an attacker and used to spoof/hijack secure parts of the site.
If the stylesheet is served from your server, then omit protocol+host part of the URL, i.e. instead of http://example.com/style.css use /style.css as the URL, so it'll work on both HTTP and HTTPS. You can also use protocol-relative URLs.
If you have to have one full URL, then use https://… URLs only.
If the requested URI is https, if you have resources on the page (images, stylesheets, JavaScript files et. al.) that are requested with the http scheme some browsers may block them because they are considered insecure. You can circumvent that per-browser, but you also have alternatives in your code:
Use https to request everything, or at least match the schems.
Use // to indicate the scheme. The browser will match the scheme with the request URI. For example: <link rel="stylesheet" type="text/css" href="//example.com/path/to.css">
Visiting my site in SSL and in Chrome (12.0) I get
Your connection to someWebsite is
encrypted with 256-bit encryption.
However, this page includes other
resources which are not secure. These
resources can be viewed by others
while in transit, and can be modified
by an attacker to change the behaviour
of the page.
The connection uses TLS 1.0.
The connection is encrypted using
AES-256_CBC, with SHA1 for message
authentication and DHE_RSA as the key
exchange mechanism.
The connection is compressed with
DEFLATE.
I searched with FireBug (NET tab) and Chrome Inspector and all resources are accessed via https. Where is the problem? *I cleared the cache already
What could be the problem?
Chrome will give this error if you've visited another https page on the same domain that had mixed content however this should not be the problem if you've tried clearing your cache.
You might want to try Ctrl-Shift-J for the JavaScript console, it should show the insecure content.
I have the same thing - and I read from the Google Chrome help site that elements on the site are not encrypted - like videos. I looked via Firefox - right click->View Page Info->Media tab and saw that every time I use a YouTube video in my video player I have plain http addresses like:
http://s.ytimg.com/yt/swfbin/watch_as3-vflrEm9Nq.swf and
http://img.youtube.com/vi/V6JgyNy59yA/1.jpg
I think these non https links are causing the security message site-wide. Thus, it appears using videos from 3rd party sites will always throw a security error in Google Chrome for https pages.
That's my answer - but I have no solution yet. I need to be able to share videos from youTube in our news section, but my online store section needs to use https without scary red letters and slashes through it for my clients.
Has anyone dealt with this effectively?
Thanks
Had the same problem on my Magento Site. Be sure to change all image and js links (even in .css) from http:// to simply //. Solved it for me.
I had the same issue, my problem was that some img tags had src to http instead of https, it does not matter even they link to other domain like <img src="http://otherdomain.com/image.jpg" /> it still shows that warning. As soon as I changed all internal and external img links to https the warning disappeared.
If you check the page and it seems to have no insecure content, check to make sure that something on the page is not submitting data to an insecure location.
Content should be submitted over HTTPS, not HTTP.
Is anyone aware of whether it is problematic to use protocol relative URLs for an image source to prevent mixed content security warnings.
For example linking an image like:
<img src="//domain.com/img.jpg" />
instead of:
<img src="http://domain.com/img.jpg" />
or
<img src="https//domain.com/img.jpg" />
In my testing i've not seen anything to suggest this is wrong but i'm not sure if it has edge cases where it will create problems.
EDIT i've seen it throw errors when using PHP's getimagesize function.
Found an interesting gotcha for the use of protocol relative URLs:
You have to be careful to only use
this syntax in pages destined for
browsers. If you put it in an email,
there will be no base page URL to use
in resolving the relative URL. In
Outlook at least, this URL will be
interpreted as a Windows network file,
not what you intended.
from here
Essentially though there are no valid reasons why this shouldn't work as long as the request is made by a browser and not an external email client.
more info from here:
A relative URL without a scheme (http:
or https:) is valid, per RTF 3986:
Section 4.2. If a client chokes on it,
then it's the client's fault because
they're not complying with the URI
syntax specified in the RFC.
Your example is valid and should work.
I've used that relative URL method
myself on heavily trafficked sites and
have had zero complaints. Also, we
test our sites in Firefox, Safari,
IE6, IE7 and Opera. These browsers all
understand that URL format
IE 7 and IE 8 will download stylesheets twice if you're using a protocol-relative URL. That won't affect you if you only use it "for an image source", but just in case.
The following should be considered when using Protocol-Relative URLs:
1) All modern browsers support this feature.
2) We have to be sure that the requested resource is accessible over both HTTP and HTTPS. If HTTP redirects to HTTPS it is fine, but here the load time will take a little longer than if the request was made directly to the HTTPS.
3) Internet Explorer 6 does not support this feature.
4) Internet Explorer 7 and 8 support the feature, but they will download a stylesheet twice if protocol-relative URLs are used for the css files.