I realise this has been discussed several times before but there still doesn’t appear to be a solution other than having a admin manually edit posts that have HTTP URLs on single lines?
Would it be possible to have an admin option something like “Disable Oneboxed HTTP URLs”?
The post that caused me to come looking for answers to this can be found here.
UPDATE: Initially I misunderstood how this problem was caused see the third post in this thread for an updated explanation.
I just found the “download remote images threshold”, which is set to 10%, it is possible that, when the post causing the problems was posted, the the disk usage was above 90%, /var/lib/docker was moved to a separate, large, partition last week, however using “Rebuild HTML” as an admin user hasn’t resulted in this being solved for this post when the first external link is to:
But I note that in this case the URL is a HTTP one that serves a Redirect to HTTPS:
lynx -head -dump http://www.progcode.org/
HTTP/1.1 301 Moved Permanently
Date: Mon, 17 Jul 2017 08:55:44 GMT
Connection: close
Cache-Control: max-age=3600
Expires: Mon, 17 Jul 2017 09:55:44 GMT
Location: https://www.progcode.org/
Server: cloudflare-nginx
So is there an issue with Redirects, in the code that tries to download images, for use as thumbnails?
This is the HTML that Discourse generates:
<img src="http://www.progcode.co/img/social-media-1.png" class="thumbnail" width="" height="">
And this is URL results in a couple of Redirects to a HTML page (not a PNG):
lynx -head -dump http://www.progcode.co/img/social-media-1.png | grep Location
Location: http://www.progcode.org
lynx -head -dump http://www.progcode.org | grep Location
Location: https://www.progcode.org/
How does Discourse determine that http://www.progcode.co/img/social-media-1.png is an image URL? Is it taken from the metadata in the site HTML?
<meta property="og:image" content="http://www.progcode.co/img/social-media-1.png" />
And if this is the case is some more checking of metadata like this needed?
It appears that in this case the error was caused by a HTTPS URL with a HTTP image URL in the site metadata that redirected to a HTML page?
Yes.
HTTP image URL is not problem here. The problem is that image not exist. If it was exist it will be fixed by download onebox images feature.
But in this case when the image is not exist I can’t understand what to do.
At the moment it appear that if the image can’t be downloaded (in this case because the URL is a HTML page) Discourse generates HTML that results in either a broken image (with a HTTPS image URL) or a broken image and a mixed content error (with a HTTP URL), I would like to suggest that neither of these outcomes is wanted — if the image can’t be downloaded shouldn’t either the Onebox display be not used for the hyperlink or should a default local image be used?
I don’t agree with @codinghorror’s reclassification of this issue as a “support” and not a “bug”.
I believe it is a bug because Discourse should check what a og:image URL resolves to before embedding it in a page in order to prevent a situation as we have on this thread, where Discourse generates a page that result in a mixed content warning. Discourse shouldn’t trust the og:image meta data on external sites without checking that it is valid first.
Feel free to submit a pull request to change the behavior if you believe it can be improved.
Thanks @codinghorror, that is fair enough, I’ll see if I can find someone to help with this, I’m not familiar enough with ruby to take this on myself.