images in articles not shown

I have a strange problem.

There is no site_config for yet. When I use the basie link I get an output with images at (klick). When I do it on my self hosted FTR the images are not displayed even if I don’t create a config. But with a right click on the placeholder icon, I can display the image in a new tab, where it immediately appears.

even with key-protection, I don’t want to post the link to my server here. I will PM this to @fivefilters

meanwhile, there is a start of a site_config on my site:

body: //div[@id='ef-content-primary']
strip: //h2[@class='ef-page-title ']
strip: //div[@id='ef-checked-out']



with safari@iOS I got images via my self hosted FTR. But not via Chrome, Edge and Firefox

OK, I think I got arround it. It seems to be a security feature of most browsers. When loading a page via https (ssl/tls), I think the browser prevents loading images from http sources.

So when the url starts with everything is fine but when it starts with or the images are missing.

Unfortunatly has no https-service and my FTR has no http-service.

But the images come from which have both http and https. But I could not manage to replace that via:


6h ago I was shure I got images with https from but currenttly that doesnt work. And the first find/replace method will do its job when spelling the domain right <g>. But it will nor show images because the site does not support https.

I will complain their admin

@HolgerAusB: The images load for me in Firefox if I load the feed via, but they don’t work on Chrome. If I open the Network panel in developer tools in Chrome while the FTR feed is loading, I see:

Mixed Content: The page at ‘…’ was loaded over HTTPS, but requested an insecure element ‘http://s1.wohin…jpg’. This request was automatically upgraded to HTTPS, For more information see Chromium Blog: No More Mixed Messages About HTTPS

So it’s Chrome that’s changing the URL just before it sends the request. This results in a HTTPS request to their server, and, as you say, their servers have not been set up to respond to HTTPS requests, so you get a broken image.

We will very likely add a new option in the config file so users can specify an image proxy service to be used for images. For example, you’d be able to ensure all images referenced in Full-Text RSS output pass through Cloudflare’s Image Optimization service: URL format · Cloudflare Image Optimization docs

This will fix cases like this because all images will have https:// URLs in the Full-Text RSS output.

yes. But this beahvior is a security standard at most current, modern browsers. And this is good!

That’s why I just complained to their data protection officer, as this may violate the GDPR.