Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Images not being displayed properly in cards generated by a link #6171

Open
coppolaemilio opened this issue Nov 8, 2024 · 12 comments
Open

Images not being displayed properly in cards generated by a link #6171

coppolaemilio opened this issue Nov 8, 2024 · 12 comments
Labels
bug Something isn't working

Comments

@coppolaemilio
Copy link

coppolaemilio commented Nov 8, 2024 •
edited
Loading

Steps to Reproduce

Whenever we share Godot news on Bluesky, we get no card image in the posts.
This is how the same input renders in three different social networks:

Twitter

image

Mastodon

image

Bluesky

image

The url of the page being shared: https://godotengine.org/article/dev-snapshot-godot-4-4-dev-4/

The website has these two elements in the <head> pointing to the image:

<meta property="og:image" content="https://godotengine.org/storage/blog/covers/dev-snapshot-godot-4-4-dev-4.webp">
<meta name="twitter:image" content="https://godotengine.org/storage/blog/covers/dev-snapshot-godot-4-4-dev-4.webp">

Our website is statically generated, so we are not dynamically pulling this data.

What platform(s) does this occur on?

iOS, Web (Desktop), Web (Mobile)

What version of the app are you using?

Build version: 1.92.1.530; Bundle info: 89cff31 (prod); Bundle date: 24101917; Platform: ios
@coppolaemilio coppolaemilio added the bug Something isn't working label Nov 8, 2024
@coppolaemilio coppolaemilio changed the title meta property="og:image" not getting pulled properly meta property="og:image" not being displayed properly in link cards Nov 8, 2024
@coppolaemilio coppolaemilio changed the title meta property="og:image" not being displayed properly in link cards Images not being displayed properly in cards generated by a link Nov 8, 2024
@mary-ext
Copy link
Contributor

image

Seems like the proxy is failing with the image request somehow, it did pull in the right image URL (https://godotengine.org/storage/blog/covers/dev-snapshot-godot-4-4-dev-4.webp)

@coppolaemilio
Copy link
Author

I wonder if it is because of the format? it being webp

@mary-ext
Copy link
Contributor

shouldn't affect it, I think. not sure who to @ here

@TimJoy-NQDM
Copy link

We have the same issue on our sites - e.g.

Getting an article works correctly - from Cardyb

https://cardyb.bsky.app/v1/extract?url=https://www.redhillandreigatelife.co.uk/news/24730322.childline-saved-life---donate-christmas/

{"error":"","likely_type":"html","url":"https://www.redhillandreigatelife.co.uk/news/24730322.childline-saved-life---donate-christmas/","title":"‘Childline saved my life’ – why you should donate this Christmas","description":"Newsquest is asking readers to help us bring hope to children over the festive season by donating cash or buying toys to support our NSPCC Christmas…","image":"https://cardyb.bsky.app/v1/image?url=https%3A%2F%2Fwww.redhillandreigatelife.co.uk%2Fresources%2Fimages%2F18770767.jpg%2F%3Ftype%3Dog-image"}

Getting the image:

https://cardyb.bsky.app/v1/image?url=https%3A%2F%2Fwww.redhillandreigatelife.co.uk%2Fresources%2Fimages%2F18770767.jpg%2F%3Ftype%3Dog-image

{"error":"Unable to serve image from URL","likely_type":"","url":"","title":"","description":"","image":""}

@TimJoy-NQDM
Copy link

For those who find this thread - make sure your image has a Content-Type Header - that seems to be the cause.

In short:

This works - and the only difference in headers is the Content-Type: image/jpeg

https://cardyb.bsky.app/v1/image?url=https%3A%2F%2Fwww.redhillandreigatelife.co.uk%2Fresources%2Fimages%2F18770767.jpg

Original image:

HTTP/2
date: Tue, 19 Nov 2024 17:32:36 GMT
cache-control: public, max-age=31622400
vary: Accept-Encoding
x-varnish: 8492755
x-azure-ref: 20241119T173236Z-179d85bf68c7n5m9hC1FRAg6es00000005m000000001nwen
x-cache: TCP_MISS
x-fd-int-roxy-purgeid: 66710783
x-m6-cacheimages: v1

New image that works:

HTTP/2
date: Tue, 19 Nov 2024 17:33:39 GMT
content-type: image/jpeg
content-length: 125162
cache-control: public, max-age=31622400
vary: Accept-Encoding
x-varnish: 10377013 16877751
x-azure-ref: 20241119T173339Z-178d4494767lcnk8hC1FRAv94c00000004u0000000011uh9
x-cache: TCP_MISS
x-fd-int-roxy-purgeid: 66710783
x-m6-cacheimages: v1
accept-ranges: bytes

@coppolaemilio - looking at your headers for your image - you also don't have the content-type header.

date: Tue, 19 Nov 2024 17:26:41 GMT
content-length: 239896
last-modified: Fri, 08 Nov 2024 18:52:22 GMT
etag: "3a918-6266b4052ef19"
x-frame-options: SAMEORIGIN
cache-control: max-age=14400
cf-cache-status: HIT
age: 6955
accept-ranges: bytes
report-to:...
server: cloudflare
cf-ray: 8e51e81f3a6ddbd4-FRA
alt-svc: h3=":443"; ma=86400
server-timing: ...

@coppolaemilio
Copy link
Author

@TimJoy-NQDM that fixed the issue! I still think Bluesky should fix it on their end, so I'll leave the issue open.

@vince-alcivar
Copy link

Adding a +1 to this issue. Does anyone know how to make sure the content-type header gets set for OG images automatically generated with NextJS?

@dbcoder14
Copy link

We are facing the exect issue, sharing on facebook, twitter and other social media, social metadata appears as they should.

But at Bluesky, that's not the case, our application is in Nuxt3

https://bold.dk/fodbold/stillinger/norge-eliteserien/nyheder/avis-fck-saelger-noah-sahsah-til-rosenborg

@Queueue0
Copy link

Queueue0 commented Dec 2, 2024 •
edited
Loading

I'm experiencing the same issue with the correct content-type for my og:image.

https://coffey.dad/blog/post/making-a-password-manager-in-go

@R-H-BDP
Copy link

R-H-BDP commented Dec 6, 2024 •
edited
Loading

This issue was first reported about 6 months ago. Tests I've performed to try and narrow down causes at the source website end...

image file extension - .jpg / .jpeg / .webp / .png etc - no correlation between image appearing or not

content-type header - images with this set correctly do not appear. I have found no other correlations between headers and images not appearing in the card (e.g. cache rules, sources etc)

twitter:image - no correlation with the tag being present or not and the image appearing

tag order - changes to the tag order (e.g. placing og:image at the top of the header or elsewhere) have no effect on whether image is presented.

other image tags (e.g. og:image:width) - no correlation with their absence and an image not being displayed.

I have not found in my logs any attempt to request images from test URLs created specifically to find out what I needed to change on my estate.

There appears to be a behaviour where once a card has been attempted from a domain that fails, further attempts at loading a card bypass the image request completely, which makes repeated testing difficult.

I have found a resource that failed to load on the Bsky web app due to ACL issues ->
https://lobster.us-east.host.bsky.network/xrpc/chat.bsky.convo.getLog?cursor=[string removed by me]

Given all the pages I tested (both on my sites and others) had correctly formed og tags, passed og verification and presented correctly on other sites where cards are supported, my conclusion is this is a BlueSky issue.

Edit: I have found no correlation between cards not appearing and browser / device combinations.

@sAnexeh
Copy link

sAnexeh commented Dec 6, 2024

I came across this issue and figured out I experience the same "Unable to serve image from URL" error message from https://cardyb.bsky.app/v1/image?url=https://my-image. I noticed that when I changed the image?url=https:// to image?url=http:// it did show up in the webserver logs where https didn't. I disabled http to https redirection on my site specifically for those images and replaced https to http on the og:image meta property and images are now being displayed correctly in cards generated by a link.

I'm using Let's Encrypt and as far as I could tell there was no SSL misconfiguration on my end, but it had been a while since I validated that. I used SSL Labs to do a quick check and saw that my site was capped to a B rating because I was missing AEAD cipher suites. After enabling those Bluesky can now succesfully fetch the image of a card on my site via https.

@zestylemon
Copy link

There appears to be a behaviour where once a card has been attempted from a domain that fails, further attempts at loading a card bypass the image request completely, which makes repeated testing difficult.

We could do with something like Meta's sharing debugger - using it forces it to scrape and cache changes & updated images.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug Something isn't working
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
9 participants
@coppolaemilio @sAnexeh @zestylemon @Queueue0 @TimJoy-NQDM @vince-alcivar @dbcoder14 @mary-ext @R-H-BDP