OG:image not working

Michiel,
I believe if you want to use secure URLs, you should -not- use the og:image tag at all. JFBConnect only uses og:image tags, and is something we may have to update after your report. For now, if you can, please remove the og:image tag and just leave the og:image:secure_url tag. Re-scan with the debugger tool, and see if that helps.

Let us know how that goes. If it fixes your issue, we can add it to our to-do list to investigate using SSL URLs for the image automatically if that's the type of page the user is already on.

Thanks,
Alex

Michiel,
What kind of SSL certificate do you have? Just want to check if it's a shared SSL certificate provided from your hosting company, or if it's one specific to your site. From the certificate chain, it looks like a standard Comodo 3rd party certificate specific to your site, which should be fine, but just want to check.

I'm doing some investigation into the Open Graph tags not working with SSL images, and so far, the only thing I've heard is that shared (or some free) SSL certs can cause a problems if Facebook can't validate the SSL provider. We just did a test with SourceCoast.com and set a secure image for one of our few secured pages, and Facebook properly detected both the secure and non-secure image provided:
developers.facebook.com/tools/debug/og/o...criptions%2Fnew%2F19

So... it seems Facebook doesn't like your site for some reason. One thing I notice now for the linter of your page is that the image it's guessing to use is:That URL doesn't work. Looking at your page, I do see the link to that image. Not sure where it's coming from. While that's likely not the issue, it may be an indicator of some configuration issues with your server/Joomla if links are being generated incorrectly or redirecting improperly. I don't have any suggestions as to where to look, but hopefully, that may give you some ideas.

Hope the above gets you started, but definitely let us know if you have any other questions or make any progress.

Thanks,
Alex

Michiel,
On the non-secure subdomain, are the images still returning a 206 status? Doing a little searching, the 206 is a status of a 'partial return of data', which is used on servers that have specific caching functions enabled. It's possible that Facebook is seeing the 'partial' data as a corrupted image, and simply not using it properly. While it would be a bug on Facebook's part if that's the issue, disabling that caching operation (and returning the full image with a 200 status code) may be the solution.

As for the bug, it's marked as low priority, which is not a good thing. It will eventually get fixed, but that may take months (from our experience). Facebook does handle https images. Our example above should show that it works. I'd really recommend investigating (or talking to your hosting provider) about disabling the 206 response if possible to see if that helps.

You may also want to post in that bug report asking if others are seeing the 206. It may also help Facebook locate the issue faster as well, in case they can't recreate it (like we couldn't).

Alex

Michiel,
Yeah, the test page I created was meant to be a wide-test case. It's an https page with both an http and https image.

If you investigate the 206 issue more, definitely let us know what you find. My guess is that the 206 is actually a server/Apache configuration more than a Joomla extension. A Joomla extension can't (easily) modify the headers on the direct read of an image (only on things that pass through Joomla's index.php file), so it's likely something lower level that's trying to be smart/tricky/cache-y to speed up static content delivery.

Hope that helps,
Alex