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...
Related
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.
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.
For some reason that I don't know the base tag at http://www.galaxy-os.kd.io?/dev (which is a PHP echo of http://galaxy-os.koding.com) doesn't work. I don't know why this is and it's really annoying. (FYI Koding.com have announced a new version with .kd.io domains which is why I'm doing this)
The links to the stylesheet and js file seem to be correct and they both work fine if I open them up manually (which means that the base tag does in fact work), but the links give a 403 error when loaded by the site itself. Maybe there is some cross domain restriction in effect?
Unfortunately, I can't provide a usable test case, since my development servers are not publicly available, however, I've been getting a bug in IE, where any time I click the back button, I get an https:// security violation error on an image that I am serving up from my own server, correctly labeled as https://
It also kills any javascript from executing, which is odd behavior, as other https:// warning did not do this.
Could anyone point me in the right direction to address this?
Just to leave some documentation, the reason for this is that IE8 doesn't like relative paths in css background-images.
I have no idea why this is, but if you use an absolute path including the https://, this will stop happening.
Production server gets a lot (hundreds) of requests which ends with -moz-zoom-in.
It just adds -moz-zoom-in to current url, e.g. http://www.wikipaintings.org/en/paintings-by-genre/allegorical-painting/-moz-zoom-in
I made a search through project and did not find any mentions of this keyword. As I understand from documentation this is related to firefox cursor type.
I wasn't able to see such requests with firebug.
Any ideas what in CSS or HTML could cause such effect?
You should have a look at the user agent string of the requests. I suspect that it is some browser that doesn't support -moz-zoom-in (meaning: not Firefox, so it is not surprising that you cannot see that request in Firebug). You probably have cursor: -moz-zoom-in somewhere in your CSS styles, probably through some third-party library like jQuery UI, and that browser "fixes" it for you and turns it into cursor: url("-moz-zoom-in"). So it actually tries to load the cursor from that URL instead of ignoring the invalid cursor.
It is a CSS cursor which indicates that an element/object in a webpage is being resized. It is part of Mozilla extensions for CSS (they begin with -moz). For more information read this.