I'm developing an ASP.Net app that is using html5shiv and ssl. For some reason I am getting mixed content errors in IE7 using html5shiv. If I remove html5shiv the errors go away. I'm also using update panels and master pages if that matters. Any ideas?
Edit: After further testing it appears to be a combination between html5shiv and a stylesheet. If either are excluded, no mixed content error.
<script type="text/javascript" src="../js/html5shiv.js"></script>
<link rel="stylesheet" href="../styles/global.css" />
Solution: I had a data uri on a header style. Removing the uri solved the problem.
Are you using the externally hosted html5shiv (on a CDN)? If so, download the file and host it yourself on the same server.
If you're using https, you need to make sure that all files are served via https. If you have any http downloads on the page, you'll get mixed content warnings.
It sounds like your html5shiv file may be being served via http, and this is causing the problem.
If you're downloading it from a third party site, check whether that site allows https downloads. If not, you may need to serve it yourself.
This ended up being an issue with a css style with a data URI. Apparently IE7 recognizes this as mixed content. The modernizer was dynamically loading a header tag which is the element the offending css style was applied to.
Related
when I give reference of CSS on third party server using http://<link to CSS> it perfectly loads the CSS.
But When I give reference using //<link to CSS> the CSS doen't load.
Tested this in chrome and firefox.
Is there any specific reason behind CSS not working with //<link> ?
Why do you want to use protocol relative urls?
If your document is on http and you are loading js in https then it wont be any issue. And if the document is https and your trying to load http then it can cause problem. May be some browsers blocked content. If your js is available on https then always use https.
Also read this discussion
I've managed it to get my Debian server with Apache2 under VestaCP running, but there's another problem.
When I try to install WordPress, nothing but plain text is shown, as css wouldn't even load (so I dont know, if the title's being correct) and yea, no design at all.
Take a look here: https://www.mrxidevelopment.de/img/i14397482092008.png
Also, after installing through that plain text stuff, I can't login.
Is that a misconfiguration of apache or have I disabled css anywhere?
Regards
One issue could be the serving up of resources over HTTPS. For example, you main site contains very many absolute paths. Maybe you had a reason for this, but it can lead to problems :)
If you change:
href="http://[whatever the uri is].css"
To:
href="//[whatever the css uri is].css"
You will then have 'protocol relative' paths.
Another pointer is using Firefox with the FireBug extension installed. You can find it here
Finally, under WordPress General Settings you can change the WordPress Address (URL) and the Site Address (URL) from HTTP to HTTPS. If you don't have access to your admin you can change this via your wp-config.php, see here for guidance on doing so.
EDIT
The issue is the paths supplied for your resources.
Try right clicking in the browser and selecting View Source. See the tag of your page. It contains all stylesheet and javascript includes.
At present, all paths are prefixed with http:// which will not work over the HTTPS protocol. My point here is to use protocol relative paths.
For example, in the Inspector (within Firefox) I changed the following line:
<link rel="stylesheet" id="twentyfifteen-style-css" href="http://www.mrxidevelopment.de/wp-content/themes/twentyfifteen/style.css?ver=4.2.4" type="text/css" media="all">
To
<link href="//www.mrxidevelopment.de/wp-content/themes/twentyfifteen/style.css?ver=4.2.4" rel="stylesheet" id="twentyfifteen-style-css" type="text/css" media="all">
The change rendered your page in my browser like this:
Note the href= attribute was the only change - but it enables successful location and load of the CSS file.
You will need to do the same for any other resources you wish to include (i.e. Images, CSS and JS etc.)
For more information see the SO questions here and here.
Just for clarity
Changing the href attribute within the Inspector (or other browser tools) is not permanent - but is a great for debugging.
To permanently fix the paths open up your source in an editor Sublime Text is great for this and edit your mark-up.
Let me know if you need any further help mate.
I'm running into an issue where I'm trying to load authenticated HTML content from a different domain via CORS. This content includes references to images, styles, and fonts.
I can load the html, images, styles, etc. but for some reason my cookie headers are not being passed along to any web fonts, resulting in a 403 forbidden error.
If after logging in, I try to access the webfont directly, I'm able to do so and it downloads fine, but it's failing inside of the #font-face at-rule in our CSS.
How can I get the browser to send along the auth cookie when it requests the web fonts? Is this possible? Is something wrong?
Thanks!
The question is quite old, but I had the same problem only in Chrome for Android.
Not tested yet but guess IOS browsers may also show this problem.
I solved adding the css which includes the font-face with jquery after authentication has been completed.
Something like:
$.when(my-function).done(function() {
$('head').append($('<link rel="stylesheet" type="text/css" />').attr('href', 'css/main.css'));
$('head').append($('<link rel="stylesheet" type="text/css" />').attr('href', 'css/font-awesome.min.css'));
});
We have two servers, a development/test server (Win Server 2008) and a live server (Win Server 2003 SP2). Same ASP.NET code base deployed to both, everything works fine Except when printing on IE 8 using the live server.
The live server prints the content shifted to the right in a larger font size.
I just don't get it! It is worth noting that we are using a specific css file for printing:
<link href="/css/print.css" type="text/css" rel="stylesheet" media="print" />
Both servers are producing identical HTML source. I am not even sure where to start looking for trouble.
If the HTML is the same then it's probably the HTTP headers that differ. Check them. It may be a MIME-type issue or something like that.
I once had a web browser ignore my CSS file because the server was sending the wrong MIME type for the CSS file.
Check what mode IE8 is using in each case. You can do this using IE8's developer tools (Press F12, it's in the menu bar at the top).
If they are different, this is likely caused byt HTTP headers, as Artelius says.
It turns out, a body element's width was not set explicitly and for some reasons that triggered the original issue, until I figured that out I have forced IE7 emulation from IIS using http headers.
My sites run off a subdomain (yyy.example.com), but I'm required to include CSS files from the main domain (example.com). We run a CMS that doesn't let me do any server-side stuff during the preview stage, so I'm stuck sending a page over https that includes a CSS import to http. All my IE users get a mixed content warning because of this.
Is there any client side way for me to prevent this, other than maintaining separate security settings for the domain on every client machine?
Make use of protocol-relative URL's in the CSS links.
Thus so
<link rel="stylesheet" type="text/css" href="//example.com/style.css">
instead of
<link rel="stylesheet" type="text/css" href="http://example.com/style.css">
It will automatically pick the protocol of the parent request, which should work fine for HTTPS as well.
As far as I know, there's no way to avoid that warning. It's there particularly for this purpose: alert you to the fact that even though you believe your page is SSL-encrypted, some of its content isn't. You'll either need to serve the original page over HTTP (not recommended), or serve the CSS file over HTTPS.
There is one proviso .. IE downloads the resources twice it seems.
http://www.stevesouders.com/blog/2010/02/10/5a-missing-schema-double-download/
When you say that you cannot do "server-side" stuff, do you mean that you cannot touch your CMS, or that you do not have root access to your HTTP server?
Because if you do have access to your HTTP server, you could set up a very simple reverse proxy (with mod_proxy if you are using Apache). This would allow you to use relative paths in your HTML, while the HTTP server would be acting as a proxy to any "remote" location. In fact this technique can also be used to mitigate some cross-site scripting issues.
The fundamental configuration directive to set up a reverse proxy in mod_proxy is the ProxyPass. You would typically use it as follows:
ProxyPass /css/ http://example.com/css_dir/
In this case, the browser would be requesting https://yyy.example.com/css/main.css but the server would serve this by acting as a proxy to http://example.com/css_dir/main.css. It will not raise the browser warning, and works fine with SSL.