I just signed up for a cloudflare account and began forcing everything to https just to see how it worked, and to my surprise, all my images refused to work over https. now this is something I don't understand because the assets are all linked via:
HTML:
<img src="./images/image.jpg" />
CSS:
background-image: url(../images/image.jpg);
So I figured, I would change it up to use absolute urls with // instead of relative paths:
HTML:
<img src="//example.com/images/image.jpg" />
CSS:
background-image: url(//example.com/images/image.jpg);
this did not work either. so I decided to hard link to https:
HTML:
<img src="https://example.com/images/image.jpg" />
CSS:
background-image: url(https://example.com/images/image.jpg);
and again, not working. what happens is the images all buffer and as soon as they are fully downloaded and displayed,they disappear abruptly.
All of the images are available over https or http so I do not understand the issue here. Would appreciate a little insight into this and whether its a cloudflare specific issue or an issue with how I'm writing my code. Can anyone confirm that relative paths should call assets via whatever protocol is currently in use? ive not seen any issue with it in the past.
Thanks in advance
Odd problem.
Would appreciate a little insight into this and whether its a
cloudflare specific issue
In general, there should be no problem to do what you are asking, there's no CloudFlare issue
or an issue with how I'm writing my code.
Both of your code examples look good to me, the first perhaps preferable because it will work with both HTTP and HTTPS
<img src="//example.com/images/image.jpg" />
Have you
ruled out browser issues by testing with another browser?
cleared the CF cache?
tested with CF set to development mode?
ruled out any app related issues by testing https image loading on a plain HTML page?
tried changing the CF SSL Level (Flexible, Full, Strict)?
if still no joy, can you post a URL?
Good luck!
As it turns out this was a Cloud Flare issue. They have a feature called Rocket Loader, which compresses all your js files into one long minified JS file which was apparently causing one of my scripts to break, only when served over https. It has been raised as a bug with Cloud Flare support (as it is odd that it works over http but not https). This particular issue was with sss.js (Super Simple Slider) the solution supplied by Cloud Flare Support was to change my script tag for sss.js from:
<script type="text/javascript" src="js/sss.js"></script>
and adding data-cfasync="false" to the tag:
<script type="text/javascript" data-cfasync="false" src="js/sss.js"></script>
Apparently this extra bit of code makes Cloud Flare's Auto-Minifier and Rocket Loader ignore that particular file.
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>
I am kinda new to both the Python language and the Heroku web interface to web-app deployment. My background is engineering, and MATLAB programming so the whole rails/web scene is new to me. But I am trying to learn the basics for an upcoming project. Towards this end, with the help of a few tutorials around the web, I have managed to successfully couple of Python/NumPy + Flask based apps:
https://matrix-spectrum.herokuapp.com/
https://plot-damped-sinusoid.herokuapp.com/
But as you can already see, in the second link, the LaTeX/MathJax mark-up is not displaying correctly. Whenever I run it on my localhost it works correctly (heroku local web), but once it is deployed that MathJax does not display.
How do I fix this? Why isn't adding:
<script type="text/x-mathjax-config">
MathJax.Hub.Config({
TeX: {
equationNumbers: { autoNumber: "AMS" },
extensions: ["AMSmath.js", "AMSsymbols.js", "autobold.js", "color.js"]
}
});
</script>
<script type="text/javascript"
src="http://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML">
</script>
in the header working? The closest question/answer I can find is:
https://groups.google.com/forum/#!topic/mathjax-users/Rpa_WQ6rMkE
But that is about 5 years, old and I suspect there should be more recent developments like:
https://github.com/pmq20/mathjax-rails
But I have no experience with "rails".
Those links use the HTTPS (encrypted HTTP) protocol, but modern browsers often refuse to load unencrypted content if the main connection is encrypted. This is called mixed content.
Your link to load the MathJax library hard-codes an unencrypted HTTP connection:
<script type="text/javascript"
src="http://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML">
</script>
You could switch http:// for https://, but a better approach is probably to simply use //:
<script type="text/javascript"
src="//cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML">
</script>
This makes your link protocol-relative; it will load using the same protocol as the page itself.
I encourage you to learn about your browser's developer tools, which are a great resource when doing web development. The console included there often reveals this type of problem.
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.
Related question here.
Boris' answer to the above question seems to make sense, but I installed the Font Awesome files on my server and the problem remains:
I looked into the library and found that the font files are included in the install, so the argument about cross-server access to fonts doesn't seem valid. I don't mind using the BootstrapCDN, but then Boris' suggestion seems to apply, and I don't know how to send the right CORS headers. (I tried it, but it doesn't work either.) Any idea how I can fix this, either using the "Bootstrap CDN" or the "default CSS"? (see also these instructions.)
PS: IE10 shows the glyph correctly.
Did you try Bootstrap CDN?
Just include <link href="//netdna.bootstrapcdn.com/font-awesome/4.0.3/css/font-awesome.css" rel="stylesheet"> in your <head> section. Font files will be loaded automatically from CDN, too.
Checked this on Firefox and it works perfectly.
#Boris says:
Firefox only allows cross-domain linking of fonts if the server the font is on sends the right CORS headers.
So it's clear that it's CDNs duty to set the right headers, not yours. And them seem to do that correctly, because Firefox doesn't complain.
If you host fonts on your own server, keep in mind that cross-domain rule may still apply, e.g. font files places under example.com may be unaccessible from www.example.com, if www.example.com doesn't send the right headers.
Read this answer for tips about bypassing cross-sub-domain restrictions - this might help in your case.
Put in a custom CSS the following (for me it solved the problem):
#font-face
{
font-family:'FontAwesome';
src:url('./fontawesome-webfont.eot');
src:url('./fontawesome-webfont.eot?#iefix') format('embedded-opentype'),
url('./fontawesome-webfont.woff') format('woff'),
url('./fontawesome-webfont.ttf') format('truetype'),
url('./fontawesome-webfont.svg#FontAwesome') format('svg');
font-weight:normal;
font-style:normal
}
[class^="icon-"]:before,
[class*=" icon-"]:before
{
font-family:FontAwesome;
font-weight:normal;
font-style:normal;
display:inline-block;
text-decoration:inherit
}
I am having same issue, we use the fonts on router board using micro httpd.
i added Access-Control-Allow-Origin: * header but not working for me.
i found in firebug that the woff file is not returing anything in response text. the same thing if i use CDN url, everything works fine. so on local micro-httpd server need some mandatory header to configure. please tell me also the exact mime types for all fonts needed.
.ttf", "application/x-font-ttf"
.eot", "application/vnd.ms-fontobject"
.woff", "application/font-woff"
.svg", "image/svg+xml"
solution to make the fontawesome css work locally is to include the files under Fonts folder into the same directory of .html files(pages).
eg:File structure as of now where fontawesome is not working
prototype\pages\.html files
prototype\styles\font-awesome\css\font-awesome.min.css
prototype\styles\font-awesome\css\fonts\fontawesome-webfont.eot,fontawesome-webfont.woff
The issue here is that for a page loaded from a file:// URI, only files in (or below) the same directory of the filesystem are considered to be "same origin", and so putting the font in a different subtree (../font/) means it will be blocked by security policy restrictions.As Firefox disables cross-domain fonts "by default.
Instead change the file structure as below:
prototype\pages\.html files
prototype\styles\font-awesome\css\font-awesome.min.css
prototype\pages\fonts\fontawesome-webfont.eot,fontawesome-webfont.woff
place the fonts folder under pages directory which fixes the issue.Hope it helps.
some-class-name:before
{
content: attr(\f021);
}
worked for me
If you are the owner of your own server, you can add a HTTP header to deal with that problem. Problem based on cross domain policies.
example.com/font-awesome.woff
boo.example/index.htm
in that case you should add that header to example.com
Access-Control-Allow-Origin = "http://boo.example"
or
Access-Control-Allow-Origin = "*"
that will make your font file reachable from other sites or specific site.
Be sure your paths are correct. Use the fa class and the icon class like:
fa fa-envelope
and will work great..
Greetings.
I am trying a simple test with the html 5 cache.
Here is a simple web page :
<!DOCTYPE html>
<html manifest="test.manifest">
<head>
</head>
<body>
<img src="http://www.somewebsite.com/picture.jpg"/>
</body>
</html>
With the following manifest :
CACHE MANIFEST
#v0.1
NETWORK:
http://www.somewebsite.com/
This work fine, the picture is displayed.
My problem is that I won't be able to know from where the picture will come. Here comes the online whitelist wildcard flag, that is supposed to solve my problem.
But with the manifest :
CACHE MANIFEST
#v0.1
NETWORK:
*
The image is not displayed (tested on safari / safari mobile / firefox).
What is not working ?
Is there another way to turn the online whitelist wildcard flag on ?
Tested in Firefox 3.6.4:
NETWORK:
http://*
Per the docs, when "the online whitelist wildcard flag is open" (i.e., the NETWORK: * format),
Subresources, such as style sheets,
images, etc, would only be cached
using the regular HTTP caching
semantics, however.
which seems to be the "what is not working". To cache subresources in the HTML5 way, the manifest must either list them in a CACHE: section, or use specific "online whitelist namespaces" as you did in your first version.
I wish to use an svg font in a webapp aimed for mobile safari (mobile safari only reads the svg font format for #font-face) Mobile safari also requires the font-ID, which is included at the end of the file name, but included after number sign (#):
font-name.svg#123456789
This is not working in the cache-manifest for the site and, with the limited feedback one gets from mobile safari, I am only guessing that the # is causing the font-id to be read as a comment, and not part of the actual file name.
Is there a way to 'trick' the cache manifest into reading this differently? Perhaps with a wildcard after the SVG? Or an ascii-only trick?