I have a strange problem.
There is no site_config for http://wohin.vienna.at yet. When I use the basie link
http://wohin.vienna.at/feed/topEventsThisWeek.rss I get an output with images at fivefilters.org (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:
strip: //h2[@class='ef-page-title ']
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
http://ftr.fivefilters.net/... everything is fine but when it starts with
https://my-ftr.example.com/... the images are missing.
wohin.vienna.at has no https-service and my FTR has no http-service.
But the images come from
s1.wohintipp.at 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
s1.wohntipp.at 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 https://ftr.fivefilters.net, 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 ‘https://ftr.fivefilters.net/makefulltextfeed.php…’ 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.