I have the problem, that my website acts different if I call it via the https protocol. To be more precise it looks like it handles the CSS in a different way.
What I want (and how it actually works via http) is kind of a navigation with different tabs. Here is an image of the navigation part:
http navigation
And here is an image of how it looks like when it's called via https:
https navigation
I have also created a fiddle with this part of my website although it does not proper work inside the fiddle. (maybe because the jsfiddle site is also via https protocol?)
Fiddle
However, please have a look at the current website to see the difference:
This is the website via http:
http website
and here how it looks like when it's called via https:
https website
You guys ever had a similar problem or any idea how to solve it?
I was the opinion that the protocol should not make a difference.
Take a look at your console.
You should see a lot of Mixed Content errors or warnings if you are using Chrome.
When a website is served over HTTPS, all its resources must be served over HTTPS too. When a resource is not loaded over HTTPS, the browser will block it because otherwise it defeats the whole purpose of using a HTTPS.
When one resource is blocked, the content from these resources won't get executed. Maybe that is the reason why your layout breaks because something is not being executed properly.
So try to change your resources into HTTPS protocol. If you are using APIs and those API does not provide HTTPS link, then you should look for another API.
In your case
This is the culprit.
http://fonts.googleapis.com/css?family=Source+Sans+Pro:300,400,700,300italic,400italic,700italic
You can find it in head section.
Your font should be in Source Sans Pro but because it was blocked, Helvetica or Arial was used instead. Thus breaking the layout.
Change it to HTTPS and it should be fine.
I don't know much about HTTP requests, but I can tell you two things:
- The browser cascades and parses CSS in different ways. HTTPS requests are processed in different ways. Maybe check you cascade.
- That website looks nice
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://
Various flavors of this have been asked already, but I've yet to see a real answer for this.
We have a separate image service that our web app uses to get some of its images. The image service is well tested and is functioning properly. To make it concrete, our app is served from domain.com. The src element of img elements is images.domain.com/{imageId}. The image service retrieves the URL for the image and sends back a HTTP 302 redirect for the image.
The application allows users to change images. So say a user 5 has image A as a profile image, and decides to change it by uploading image B. When the user uploads the image, the application cache is properly invalidated and the database is updated. The application does a standard redirect after POST and one of the elements in the page that the user is redirected to after changing her image is something like:
<img src="example.domain.com/5">
The problem is that Chrome never makes the call to example.domain.com/5 to retrieve the image upon the initial redirect or a regular reload of the page, it simply serves image A from the browser cache. A standalone call to example.domain.com/5 correctly returns image B, and a hard refresh or clearing Chrome's cache forces Chrome to request the image's src, which correctly returns image B. Note that I'm not talking about serving either image from the cache after getting a 304 Not Modified response, I'm talking about Chrome deciding not to visit the img src at all and just returning image A. Also, appending some unique query string to the img's src attribute fixes the problem, but that's a hack that we'd rather not have to do.
It's worth noting that Firefox was doing the same thing initially. There were no Cache Control headers in the response initially. We added a Cache Control: no-cache header (and tried no-store as well) to the response header and this fixed the behavior in Firefox, but Chrome and Safari still serve the outdated, cached image without making a call to the image's src.
It looks like this was a longstanding bug in Chromium (https://code.google.com/p/chromium/issues/detail?id=103458) that's allegedly fixed as of about 6 weeks ago, but we're using the most updated version of Chrome.
We've looked at the answers here and here but they don't actually answer the question.
Per section 14.9.1 of RFC 2616:
If the no-cache directive does not specify a field-name, then a cache MUST NOT use the response to satisfy a subsequent request without successful revalidation with the origin server. This allows an origin server to prevent caching even by caches that have been configured to return stale responses to client requests.
Unless we're missing something or doing something wrong, it would seem that Chrome (and Safari) are not complying the RFC behavior for no-cache headers for 302 redirects? Anyone experience this before or have any insight?
cache-control: no-store
I had the same maddening problem that you described (slightly different in that it was a missing cookie redirect back to the login page) that worked everywhere but Safari.
In desperation, I came across this open WebKit bug and saw the fateful comment (and finally a glimmer of hope):
CachedRawResource now keeps the redirect chain, and has some trivial logic for checking correctness, but it's nowhere near complete (only checks cacheControlContainsNoStore()). And of course other resource types don't have anything.
Added no-store to my cache-control header and no more problem.
Please read this.. https://www.hochmanconsultants.com/articles/301-versus-302.shtml
Chrome has pretty aggressive caching.
When you use a temporary redirect, you are basically saying that the actual URL is temporarily unavailable so use this other URL instead. Chrome rightly caches the old URL because it is still valid. Try a 301 instead. Then Chrome should know that the original URL is no longer valid.
I have a very small static site (http://www.codeinside.eu/) and tested it via Google Pagespeed. It told me I should use compression for the page and all JS/CSS files - but here is my problem: I thought that my website is already running with compression.
The website is running on Windows Azure Websites and is based on ASP.NET. For CSS/Javascript I use the builtin Bundling feature and the Website should run in release mode - so bundling and minification works fine and as far as I know IIS8 should compress dynamic content.
Then I tried another testing instrument http://www.whatsmyip.org/http-compression-test/ which said that my site is compressed.
My website and several other websites running ASP.NET and IIS (including stackoverflow.com) don't include the "content-encoding:gzip" header in the response - is this a problem with the Pagespeed analyser or is this a problem of IIS? Or is this no problem at all because the header is not that important?
Edit: Of course the browser sends the "accept-encoding:gzip" header in the request.
Found the solution for this issue:
We use the Microsoft TMG as a Proxy in our company and it seems to remove the "Content-Encoding" header (and other magic stuff). I was confused because some pages like twitter.com are served to my PC with the "content-encoding: gzip" header and other without any "Content-Encoding" header.
My wild guess: The TMG is case sensitive and only looks for "Content-Encoding", that's why I receive some requests with it and some without it.
So - compression with the correct header works as expected.
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.
In Firefox, I view my site and get no warnings about insecure mixed content.
Using FireBug, I can see that every request is https.
In Chrome, I get the https crossed out in the address bar.
I viewed source in Chrome and then ran this regex /http(?!s)/ but the only things it found were the href attributes for some external links and the doc type and http-equiv meta tags.
Using Chrome's Resource Tracking revealed all requests were https too.
This includes Google Analytics, jQuery from Google's CDN and Facebook like scripts.
Is there any specific tool I can use to show non https requests, or anything further I can try?
I found that I get the "mixed content"-warning in Chrome even when there is no mixed content, if sometime during the session mixed content was already encountered on the domain.
(Also mentioned here: Why is Chrome reporting a secure / non secure warning when no other browsers aren't?)
In Chrome's Developer Tools, the Console tab shows the resources that it won't load because they unsecure.
You can add the "scheme" column to the Chrome developer tools network tab to show which requests were sent over http or https:
Press F12 to show the developer tools
Switch to the Network tab
Right click in the column headers and select "Scheme"
Reload the page to show which elements are loaded over http or https
In situations like this where it's helpful to see exactly which protocol is being used to load resources, I would recommend Fiddler2 as a browser-agnostic solution that can show you exactly what traffic is occurring on each request.
From the site:
Fiddler is a Web Debugging Proxy which logs all HTTP(S) traffic between your computer and the Internet. Fiddler allows you to inspect all HTTP(S) traffic, set breakpoints, and "fiddle" with incoming or outgoing data. Fiddler includes a powerful event-based scripting subsystem, and can be extended using any .NET language.
Edit: In-browser debugging tools are becoming really good so this third-party tool may not be as useful as it was when this answer was first written.
Open up the Web Inspector and find the yellow triangle (warning) in the top right. Click on it and it will display all security issues.
In 48-th version of chrome they added a security panel. Using it you can quickly identify the mixed content resources:
Do you have the HttpFox plugin for FireFox? That'd work, I think.
Among other things, it reports on the URL, Method, Result Code, and bytes of all the assets that a web page requests. It's what I've used to trap the occasional non-HTTPS graphic, etc. I'm sure the other suggested tools would do the same...
You can use SslCheck
It's a free online tool that crawls a website recursively (following all internal links) and scans for nonsecure includes - images, scripts and CSS.
(disclaimer: I'm one of the developers)
I know this post is old, but I ran across it and had the same issue. I clicked on the Chrome menu (top right corner), scrolled down to Tools> and selected Developer Tools. Clicked on the Console tab and it told me exactly what the problem was... the favicon was served over http, not https, but of course it was not in the page source code. Corrected the problem in my CMS, which loads the favicon without code in the page... and no more error!
Note that 'mixed content' and 'mixed scripting' are detected seperatly. Check this site for the meaning of the icons in Chrome: https://support.google.com/chromebook/answer/95617?p=ui_security_indicator&rd=1 (click 'see details' link).
Grey icon = mixed content, red icon = mixed scripting.