My site loads external javascript with relative protocol, i.e.
<script type="text/javascript" src="//somewhere.com/script.js"></script>
(Note: the script tag is injected asynchronously to fetch the script after page load.)
but my dns-prefetch tag is absolute protocol, i.e.
<link rel="dns-prefetch" href="http://somewhere.com/script.js">
so when the site is loaded over HTTPS the prefetch is http and the script is https. There is no warning in the Chrome console about this.
Besides keeping these consistent, is there any performance benefit to changing the dns prefetch link to relative protocol?
One thought I had was that because all dns prefetch supposedly does is resolve an IP from a hostname, it might actually be beneficial to use http in the prefetch to avoid needing to do the SSL handshake. But this assumes the dns-prefetch link instructs the browser to make a network request, which I'm not sure is what's happening.
The following three lines, when supported by the browser, do the same:
<link rel="dns-prefetch" href="http://SERVERNAME/some.script.js">
<link rel="dns-prefetch" href="https://SERVERNAME/some.script.js">
<link rel="dns-prefetch" href="//SERVERNAME/some.script.js">
They all try to request A and AAAA resource records from the DNS resolver, if such information is not already present in the browser name service cache.
Therefore, the performances are the same.
Related
I am trying to to use a texture from my own hosted webserver but putting it into the asset-item tag I get the following error.
> Access to Image at 'http://192.168.137.1:3000/cat2.jpg' from origin
> 'http://localhost' has been blocked by CORS policy: No
> 'Access-Control-Allow-Origin' header is present on the requested
> resource. Origin 'http://localhost' is therefore not allowed access.
The picture is accessible, since I can see it in the webinspector.
It works perfectly in a simple image tag. Does anyone know what to do here?
Thanks!
Update: My code you could find below:
<script src="https://aframe.io/releases/0.5.0/aframe.min.js"></script>
<a-scene>
<a-assets>
<img id="cat" src="http://192.168.x.x:3000/cat.jpg"/>
</a-assets>
<a-sky src="#cat"/> <!-- this code works not (CORS) -->
<a-sky src="http://192.168.x.x:3000/cat.jpg" /> <!-- this code works not (CORS) -->
</a-scene>
<img id="cat" src="http://192.168.x.x:3000/cat.jpg"/> <!-- this code works -->
Solution:
I figured out the main problem: It had nothing to do with A-Frame itself, it was a minor mistake on the server. The headers were specified after the fileserver was initialized. Putting the specification in the initialization phase did the trick... of course... :-D
What's CORS?
This is not A-frame or Three.js or WebVR that is an issue. CORS (Cross-origin resource sharing) happens when the JavaScript (in your situation is that this script https://aframe.io/releases/0.5.0/aframe.min.js ) makes a cross-domain XHR (XMLHttpRequest) call (in your situation is that to http://192.168.x.x:3000/cat.jpg ).
On Wikipedia I've found an image that gives more information about the workflow of CORS.
Your request is a GET-request, there are custom HTTP headers and didn't add Acces-Control-* headers, result an error.
More information about CORS I've found on the Mozilla Developer Network.
Documentation from A-frame
Why does my asset (e.g., image, video, model) not load?
First, if you are doing local development, make sure you are using a local server so that asset requests work properly.
If you are loading the asset from a different domain (and that you do), make sure that the asset is served with cross-origin resource sharing (CORS) headers. You could either find a host to serve the asset with CORS headers, or place the asset on the same domain (directory) as your application.
Why is this happen?1
It looks like the script (https://aframe.io/releases/0.5.0/aframe.min.js ) that must be added, loads the images and that's why <a-sky src="http://192.168.0.253:457/cat.jpg" /> is not working at all. Because the image is loaded from the script that is hosted on A-frame.
If you use <a-assets><img src="http://192.168.0.253:457/cat.jpg" /></a-assets>, the image URL is bound to the a-skys src-attribute. And again the image is loaded from the script on A-frames server and makes a cross-domain XHR call.
1 I'm not 100% sure, but there is a big chance that it's correct. If anyone think that this is not correct, please say it. If it is correct, please say it also.
Solutions
Place the file on your local host web server.
Add the response header Access-Control-Allow-Origin when the image is requested. I think, the value must be http://aframe.io.
After many trial and error, I finally found a way to incorporate images from remote server to my local server without facing CORS errors. The solution is using a CORS proxy instead of doing direct request.
Despite the following code is not the most elegant solution, it works for me.
<!DOCTYPE html>
<html>
<head>
<title>
</title>
<script src="https://aframe.io/releases/0.9.2/aframe.min.js"></script>
</head>
<body>
<a-scene>
<a-assets>
<img id="frodo" crossorigin="anonymous" src="https://cors-anywhere.herokuapp.com/http://i.dailymail.co.uk/i/pix/2011/01/07/article-1345149-0CAE5C22000005DC-607_468x502.jpg">
</a-assets>
<!-- Using the asset management system. -->
<a-image src="#frodo"></a-image>
</a-scene>
</body>
</html>
Using CORS Proxy, adds all the headers needed to perform the request to the remote server and gather the objects in the src field.
Please note that the src request is: https://cors-anywhere.herokuapp.com/<url_you_are_looking_for>
Hello i have an issue with my domain and ssl, when you enter to https://www.limitx.com.mx you can see a error with a ssl encryption, your connection is encrypted with modern cryptography, how i can solve this? i dont know how to fix this issue, i hope can help me. Bes regards guys!
You have two resources on your home page that are served over HTTP (mixed content).
Mixed Content: The page at 'https://limitx.com.mx/' was loaded over
HTTPS, but requested an insecure stylesheet
'http://fonts.googleapis.com/css?family=Roboto:400,900,300,700'. This
request has been blocked; the content must be served over HTTPS.
This is coming from the main file that is generating the HTML:
<link href='fonts.googleapis.com/css?family=Roboto:500,300'; rel='stylesheet' type='text/css'>
You'll need to change this to be
<link href='https://fonts.googleapis.com/css?family=Roboto:500,300'; rel='stylesheet' type='text/css'>
Mixed Content: The page at 'https://limitx.com.mx/' was loaded over
HTTPS, but requested an insecure image
'http://limitx.panamerik.net/skin/frontend/ultimo/default/images/infortis/_shared/generic-nav/buscar.png'.
This content should also be served over HTTPS.
This is coming from https://limitx.com.mx/skin/frontend/ultimo/default/css/styles.css
.form-search .button {
...
background-image: url(http://limitx.panamerik.net/skin/frontend/ultimo/default/images/infortis/_shared/generic-nav/buscar.png);
...
}
You cannot use an HTTPS version of this URL as the certificate for http://limitx.panamerik.net/skin/frontend/ultimo/default/images/infortis/_shared/generic-nav/buscar.png does not match the host.
You can copy this file (buscar.png) locally, perhaps under skin/frontend/ultimo/default/images/infortis/_shared/generic-nav/ and change the CSS to be
.form-search .button {
...
background-image: url(../images/infortis/_shared/generic-nav/buscar.png);
...
}
Well the issue is that other objects on your page are not using ssl, do you have any embeded links that have http instead of say https? I would check those images, they are most likely the culprit. Instead of using relative paths try hardcoding all the images with https://url to image/ alright? That should fix ya up good. Nice site btw.
For your Firefox issues: https://support.mozilla.org/en-US/questions/967766
The only way for websites to "supply ownership information" would be through a secure connection and an "Extended Validation Certificate" which will cost a few hundred USD and upwards per year at the relevant certificate authorities: https://en.wikipedia.org/wiki/Extended_Validation_Certificate
Google Issues: https://support.google.com/chrome/answer/95617?p=ui_security_indicator&rd=1
Your connection to the site is encrypted, but Google Chrome has detected mixed content on the page. Be careful if you're entering information on this page. Mixed content can provide a loophole for someone to manipulate the page. This content could be third- party images or ads embedded on the page.
Internet Explorer.....doesnt see any issues at all.
We're getting allot of Mixed Content errors on the cart page of our Magento Store
Mixed Content: The page at 'https://www.magento.com/onestepcheckout/index/' was loaded over HTTPS, but requested an insecure stylesheet 'http://fonts.googleapis.com/css?family=Lato:400,300,700,900'. This request has been blocked; the content must be served over HTTPS.
I can see the google font file is being called in the head section of our theme via http
<link href='http://fonts.googleapis.com/css?family=PT+Sans' rel='stylesheet' type='text/css'>
I'm wondering what is the best way to solve this issue should I change the line above to:
Option 1
<link href='https://fonts.googleapis.com/css?family=PT+Sans' rel='stylesheet' type='text/css'>
OR
Option 2
<link href='//fonts.googleapis.com/css?family=PT+Sans' rel='stylesheet' type='text/css'>
Which is the best method considering most of our site uses http? I was not aware of Option 2, it seems like a very good approach.
I found a good answer here.
The second option, protocol relative links seems to be the best option.
UPDATED ANSWER
To give a more complete answer, protocol relative URLs help to avoid Mixed Content errors by requesting the resource from whatever protocol the browser is viewing that current page through. This is really useful when your site has pages that use both http & https, as in my case checkout page was being loaded over https while the rest our site uses http.
Example
So if we use a protocol relative url to link to a resource.
<link href='//fonts.googleapis.com/css?family=PT+Sans' rel='stylesheet' type='text/css'>
When we're on https://www.magento.com/onestepcheckout/index/ the resource will be loaded via https, https://fonts.googleapis.com/css?family=Lato.
And if we're on http://www.magento.com/ the resource will be loaded via http http://fonts.googleapis.com/css?family=Lato
This will avoid any Mixed Content Errors.
Caveats
There are a few things to consider when using this approach though.
IE6 does not know how to hanler protocol relative urls. IE6 has less than 1.7% of the browser market.
IE7 & IE8 support protocol relative URLs but they’ll end up fetching the
resource twice. Once from HTTP and once over HTTPS, which will slow
things down. Again, these older browsers account for very little of the browser market.
Does not work in all email clients (e.g Outlook), so avoid using protocol relative urls in HTML emails
You have to be sure that the server you’re requesting from is capable of serving content over both HTTP and HTTPS. If not you might end up fetching content from an unsecured or nonexistent server port.
Further Reading
https://developer.mozilla.org/en-US/docs/Security/MixedContent/How_to_fix_website_with_mixed_content
http://www.paulirish.com/2010/the-protocol-relative-url/
http://billpatrianakos.me/blog/2013/04/18/protocol-relative-urls/
I got the exact same error while adding products to cart, I was deploying CDN for Magento 1.9 let me share my solution,
Accoriding to Chrome Console, the URL returned by js about ajaxcart started with HTTP , so I go to review the parameter construture I found this :
js/cmsmart/jquery/ajaxcart/cmsmart-ajaxcart.js: var myajaxcart = baseUrlAjax + 'ajaxcart/index/index/id/';
js/cmsmart/jquery/ajaxcart/cmsmart-ajaxcart.js: var urladdajaxcart = baseUrlAjax + 'ajaxcart/index/index/';
js/cmsmart/jquery/ajaxcart/cmsmart-ajaxcart.js: var checkouturl = baseUrlAjax + 'checkout/cart/add/';
and baseUrlAjax is controlled by PHP echo $url
app/design/frontend/default/theme691/template/cmsmart/ajaxcart/page/head.phtml: var baseUrlAjax = '<?php echo $url; ?>';
and $url is controlled by
app/design/frontend/default/theme691/template/cmsmart/ajaxcart/page/head.phtml >>>
#$url = Mage::getBaseUrl(); #oldone
$url = Mage::getUrl('',array('_secure'=>true)); # set to this new one
Bingo!
Reffered to this page : How Do You Get The Store Secure URL in Magento?
Why doesn't embedding google fonts work on Heroku?
For example:
<link href='http://fonts.googleapis.com/css?family=<some_kinda_font>' rel='stylesheet' type='text/css'>
EDIT: turns out it works, one of my chrome extensions was blocking it as an "insecure script"
I discovered that heroku sets security parameters for using the google fonts url. It wants to use the https instead of plain http. Here's what worked for me.
Instead of:
#import url('http://fonts.googleapis.com/css?family=Oswald:400,700,300');
I used
#import url('//fonts.googleapis.com/css?family=Oswald:400,700,300');
If you notice the second line leaves out the http, allowing heroku to use https. I'm assuming you could probably use https in the link if you wanted to.
Simply use HTTPS instead of HTTP:
<%= stylesheet_link_tag "application", 'https://fonts.googleapis.com/css?family=<font_name>', :media => "all" %>
Change link to HTTPS
<link href='https://fonts.googleapis.com/css?family=some_kinda_font' rel='stylesheet' type='text/css'>
A better approach is to leave off the protocol altogether and just start with '//'. The correct protocol (HTTP or HTTPS) will be used depending on server context
<link href='//fonts.googleapis.com/css?family=some_kinda_font'
rel='stylesheet' type='text/css'>
Or you can use the url without specifying the http protocol
<%= stylesheet_link_tag "application", '//fonts.googleapis.com/css?family=<font_name>', :media => "all" %>
With this both http and https work.
The #import generates blocking CSS, which causes a slower page load. Using an extra DNS lookup for your fonts makes this even worse. To improve performance I would swap #import with #font-face and host the fonts locally/on your own web server. You can download the fonts using the Google Fonts download helper.
IMPORTANT NOTE - Putting your company name in front of something that is released for free to the community is uncool (Google Fonts). Using this to create a 'free service' to track the behaviour of people online is even more uncool. Most people call this stealing (plagiary) and snooping. We tell our kids that this is bad. We (as web developers) should not facilitate this. We should NOT feed Google Fonts to our visitors. Just download these free fonts and serve them from your webserver. They (should) have nothing to do with Google. If you are the owner of any of these fonts, please prevent Google from hosting them. Stop facilitating mass surveillance. Thank you.
I have all my site images setup to serve from Amazon's Cloudfront CDN. If my pages will sometimes be served as both HTTP and HTTPS, then should I make all image paths HTTPS to the CDN?
Is this a poor practice?
Any other ideas?
Making all image paths to the CDN be over HTTPS is definitely a bad idea. There is a significant overhead with each HTTPS request, so you might not want to do that.
However, turns out there is a simple solution to specifying absolute, cross-domain URLs without the protocol. Simply use, in your css, something like
url: (//d604721fxaaqy9.cloudfront.net/image.jpg) ...
and make sure that your stylesheet is being served over the same protocol, either by using the same trick, or preferably by specifying a path without the protocol, i.e., something like
<link href="/styles.css" ...
or
<link href="styles.css" ...
and you're good to go!