When i brows website using its ip address the style loading fine. But when i try to do it using domain name then style not working. The interesting thing is that i have checked both output html, css source for code and they are 100% same. Then why browser not showing style in domain mode?
direct ip browse- view-source:http://22.199.66.33/
domain browse- view-source:https://www.ogibogi.com/
here i checked both source output code- https://www.diffchecker.com/diff
Any idea how to fix it?
Note: i am using cloudflare with domain.
Note: that this is happening after changing hosting server.
Check the output in your browser's console. There's mixed content error.
Refer to Cloudflare KB on how to troubleshoot mixed content error.
An easy fix is to enable "Always Use HTTPS" and "Automatic HTTPS Rewrite".
The answer from Faiz is correct. Go to the crypto tab and set Automatic HTTPS rewrites to on. But, that will not affect stylesheets or javascript files. And, you have two missing scripts and one missing css file.
To correct those, you'll need to use a relative reference. If you're calling an asset with a full URL, like <img src="http://example.com/image.jpg" />, you would want to change this to <img src="//example.com/image.jpg" />. By removing the http:, the browser will use whichever protocol the visitor is already using. And, on the crypto tab, if you set Always use https to on, that protocol will be https.
Related
I've been looking around, and I find something that for some reason works for some links, but when I try to download my image it just opens the page with the image
Download
I expect this to download the imgur image I linked, but it just opens the link instead, any ideas how to fix this?
I've just made a quick test and it seems like that origin domain matters in this case.
The download attribute works fine if the image is on the same domain. Otherwise it opens the link.
This attribute only works for same-origin URLs.
Although HTTP(s) URLs need to be in the same-origin, blob: URLs and data: URLs are allowed so that content generated by JavaScript, such as pictures created in an image-editor Web app, can be downloaded.
If the HTTP header Content-Disposition: gives a different filename than this attribute, the HTTP header takes priority over this attribute.
If Content-Disposition: is set to inline, Firefox prioritizes Content-Disposition, like the filename case, while Chrome prioritizes the download attribute.
According to the MDN description of the download attribute:
This attribute only works for same-origin URLs.
So it won't work with a URL that points to a different domain than your own, such as i.imgur.com.
You can use a proxy script on your own server, something like:
Download
Then write the image_download.php script that does:
readfile($_GET['url']);
You should of course have validation checks in the script so that it doesn't get abused as a general-purpose proxy by third parties. Google "php proxy" and you'll find some pre-written scripts.
The download attribute only works for same origin URLS.
You could either write a server side script.
OR
Take a look at this discussion for a quick workaround.
Simply insert your URL into the downloadResource() like so: downloadResource('https://i.imgur.com/KBUpwNd.jpg'); Wrap in script tags and run on your browser.
I am trying to display images from a non-ssl url source on my ssl site through relative linking, making sure the padlock shows up green and does not message mixed content. Though I understand this might not be the best way going forward I have 2 questions:
1) I have 2 sources:
http://bc01.rp-online.de/polopoly_fs/benito-raman-fortuna-duesseldorf-2017-1.7053738.1516622253!httpImage/1633501625.jpg_gen/derivatives/d950x950/1633501625.jpg
and
http://bilder.bild.de/fotos-skaliert/prinzessin-eugenie-ist-verlobt-200668711-54556312/3,w=120,c=0.bild.jpg
If I convert the first source to:
//bc01.rp-online.de/polopoly_fs/benito-raman-fortuna-duesseldorf-2017-1.7053738.1516622253!httpImage/1633501625.jpg_gen/derivatives/d950x950/1633501625.jpg
it will not be displayed in Chrome.
If I convert the second source to:
//bilder.bild.de/fotos-skaliert/prinzessin-eugenie-ist-verlobt-200668711-54556312/3,w=120,c=0.bild.jpg
it will be displayed in Chrome and padlock shows green.
Can someone explain me the difference?
2) Is there a better way to show images from non-SSL URL's external sources in a SSL site making sure the padlock is green.
Any help would be highly appreciated.
Funny you should post this. I had a really odd behaviour for something similar to this today and you have no choice but to use //example.com/...... and this is just a (Google) Chrome thing.
The difference here is that in using //, it will automatically resolve to the respective protocol; which you should use and this for JS scripts, images, forms etc.
NOTE: If there is any mix of http/https anywhere in your code, then that too will cause havoc and will throw a message in any browser about mixed content.
If your urls starts with "//" it means that the browser should use the protocol of the parent webpage. In your case it's https.
So your two links becames:
https://bc01.rp-online.de/polopoly_fs/benito-raman-fortuna-duesseldorf-2017-1.7053738.1516622253!httpImage/1633501625.jpg_gen/derivatives/d950x950/1633501625.jpg
But bc01.rp-online.de doesn't have a valid https certificate.
and
https://bilder.bild.de/fotos-skaliert/prinzessin-eugenie-ist-verlobt-200668711-54556312/3,w=120,c=0.bild.jpg
which works perfectly.
If you include http images in your https website, chrome doesn't show the "secure" green padlock because your website is not fully secure: some items may be intercepted/modified by a third party.
To have the green padlock you should only use secure (https) images/resources. If these images are not available with https (or if their https links are broken or redirect to http) then you need to find another solution, such as hosting yourself the images.
Is there a reason we include the http / https protocol on the href attribute of links?
Would it be fine to just leave it off:
my site
The inclusion of the “http:” or “https:” part is partly just a matter of tradition, partly a matter of actually specifying the protocol. If it is defaulted, the protocol of the current page is used; e.g., //www.example.com becomes http://www.example.com or https://www.example.com depending on the URL of the referring page. If a web page is saved on a local disk and then opened from there, it has no protocol (just the file: pseudo-protocol), so URLs like //www.example.com won’t work; so here’s one reason for including the “http:” or “https:” part.
Omitting also the “//” part is a completely different issue altogether, turning the URL to a relative URL that will be interpreted as relative to the current base URL.
The reason why www.example.com works when typed or pasted on a browser’s address line is that relative URLs would not make sense there (there is no base URL to relate to), so browser vendors decided to imply the “http://” prefix there.
URLs in href are not restricted to only HTTP documents. They support all the protocols supported by browsers- ftp, mailto, file etc.
Also, you can preceed URL name with '#', to link to a html id internally in the page. You can give just the name or directory path, without a protocol, which will be taken as a relative URL.
My solution was to trick the browser with a redirect service, such as bit.ly and goo.gl (which will be discontinued soon), in addition to others.
When the browser realizes that the url of the shortcuts is https, it automatically releases the link image, the link is released and instead displays the http image, without showing the original link.
The annoying part is that, according to the access, it will display in the panel control of your redirector, thousands of "clicks", which is actually "display".
With this experience I'm going to look for a Wordpress plugin for redirection and create my own "redirects links". So I will have https // mysite.com /id → redirect to http link.
I have a weird problem. I generate a HTML page, hosted let's say at http://www.x.com/stuff which contains
<head>
<link type="application/atom+xml" rel="alternate" href="/stuff/feed"/>
..
</head>
The result is:
In IE7 all works well - you can click on the feed icon in the browser and the feed is displayed
In Firefox, view source, click on the linked /stuff/feed and you see the source of the feed, so that works as expected
In Firefox, view the page (not source), then click on the feed icon in the address bar, I get an error that it can't retrieve the URL feed://http//www.x.com/stuff/feed
So the problem is, that it's appending feed:// to the front of the URL and then taking out the colon : after the http. I understand that feed: is HTTP anyway so perhaps the adding of that isn't a big problem.
But anyway, the fact is, that URL Firefox generates out of my <link> tag doesn't work.
I have considered making the URL absolute, but I haven't found any evidence that those URLs have to be absolute, nor can I understand why that would be the case. And for various reasons it would be inconvenient in my code to generate an absolute URL. I can do it if necessary but I would prefer to see proof (e.g. specification, or Mozilla bug report) that it's necessary before making my code messy
What do you think? Does anyone know of any evidence that the URL should be absolute? Or am I doing something else wrong? It seems such a simple/obvious tag, where nothing could go wrong, but I can't get it to work.
I had the same problem. IT was caused by the proxy server at work that my web traffic was going through. Firefox changed "http://server.tld/feed-url" to "feed://http//server.tld/feed-url". Since the web proxy that all my http traffic is going through does not recognize the "feed://" protocol, it rejects my request as invalid.
The only workaround I have found so far is to manually configure the proxy settings in Firefox. Right now you probably have them automatically configured by your system. If you know your proxy information, you can instead manually configure it. Doing so only for http/https/ftp allowed me to access the feed because Firefox then handled the feed:// URL directly (which ended up with it redirecting to http:// like I wanted).
To configure your proxy settings directly, you'll need to go to Edit -> Preferences -> Advanced -> Settings (next to "Connection"). Use manual settings. You'll have to determine the proxy settings that your system is already using.
Note that the missing colon (mentioned by Piet) is not a bug on your site. It's a conversion that the Firefox subscribe is doing. Also note that it is not a problem caused by a relative URL as Julien suggests. Firefox is converting it to an absolute URL, but then removing the colon in the http:// protocol prefix so that it can be appended to "feed://" (changing the protocol and supplying the original absolute URL as the "URL" for the new "feed" protocol).
Can you provide a link to your site or the specific HTML-page to see this live? Because the ATOM-feed of this question on SO is announced exactly the way you try to link your ATOM-feed:
<link rel="alternate" type="application/atom+xml" title="Feed for question 'Link to RSS/Atom feed, relative, doesn't work in Firefox'" href="/feeds/question/4438794">
This works fine with my Firefox/3.6.13.
The fact that the non-working base URL contains a typo is suspicious: that would happen if something is overriding it by accident.
Does your page contain a bad base element? The base element (and RFC 1808) is not supported exactly the same across all browsers, so if you have something like this in your document (note the missing :):
<base href="http//www.x.com/">
then it might be used inconsistently by browsers to resolve relative references, depending on element placement, rendering mode, error fallback behavior, or other factors.
If the document contains no base element, check that you aren't accidentally introducing an incorrect base URL through some other means, such as the Content-Location HTTP header.
This is a bug in Firefox or FoxyProxy or something.
Not only do I see exactly the same problem for stackoverflow (go to a question in Firefox, click on the feed icon, see the same weird feed://http//... URL) but also on http://news.google.com/
I have written to a friend at a completely unrelated company, he sees the same error from his FireFox on those standard internet pages.
It doesn't help to use absolute URLs in the <link> tag; news.google.com uses absolute URLs, for example.
It turns out, if you go to the proxy settings in Firefox, if you select "Use System Proxy Settings" this happens; if you enter proxy details manually or use no proxy, this problem doesn't occur.
This seems to be this bug here http://foxyproxy.mozdev.org/drupal/content/problem-with-feed-and-proxy
Put an absolute URL, it's a good practice for elements and won't break browsers...
Just wanted a confirmation for this: Firefox currently doesn't play well for picking custom fonts through a sub-domain via the font-face tag. Other browsers do this without any problems.
A little research showed up saying that i am required to set the Access-Control-Allow-Origin as is shown in the link here: http://pastie.org/653265
Essentially i have my blog at kaushikgopal.com/blog and i was trying to
access fonts that within this blog that are available at
font.kaushikgopal.com. I tried changing the same in my .htaccess file but couldn't resolve the issue.(I placed a .htaccess file within the font sub-domain folder and directly pasted code from the above pastie link).
I submitted a ticket to dreamhost asking for assistance and they were helpful in clearly stating "We do not support Access-Control-Allow-Origin on shared hosting servers".
So i didn't go the sub-domain route for fonts. But i'm a little curious, has anyone tried this (with a dreamhost hosting account would be helpful)? Just want to confirm what the tech-support guy suggested is accurate and there's no other way.
Thanks.
Another nice link clearly stating the problem :
http://www.stevesouders.com/tests/font-face/xdomain.php
I just tried and it does work (on Dreamhost). Eg, /mysite/pub/.htaccess:
header add Access-Control-Allow-Origin *
See http://42at.com/lab/Thumboard/bookmarklet.html. The bookmarklet does an ajax call to my domain, and with above access-control is able to grab html snippet.