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.

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

open graph image urls are relative and may not work for non-relaxed implementations #11081

Closed
1 task done
eleith opened this issue Jul 14, 2024 · 0 comments · Fixed by #11082
Closed
1 task done

open graph image urls are relative and may not work for non-relaxed implementations #11081

eleith opened this issue Jul 14, 2024 · 0 comments · Fixed by #11082

Comments

@eleith
Copy link
Contributor

eleith commented Jul 14, 2024

The bug

sometimes, the open graph image from a shared link is not found, resulting in no image preview (ex: signal app on android)

The OS that Immich Server is running on

n/a

Version of Immich Server

latest

Version of Immich Mobile App

latest

Platform with the issue

  • Web

Your docker-compose.yml content

n/a

Your .env content

n/a

Reproduction steps

1. generate a share link from immich
2. share the link on a social network that implements a strict form of the open graph protocol
3. note that the image preview is not found / is broken

Relevant log output

n/a

Additional information

when sharing a link from immich on social networks / messaging apps / etc, a preview is grabbed from the og:image value in the headers of the sharing page.

the value is currently a relative path to a thumbnail of the first asset being shared. many implementations will correctly concat this path to the base URL of the share link.

however, not all implementations will do this correctly (ex: signal on android), so many opengraph checkers will not show any broken behavior.

the opengraph protocol itself doesn't make this immediately clear, but later in the document (and the turtle spec), they do declare that url values are defined as:

All valid URLs that utilize the https:// or https:// protocols

all examples in the document also make use of fqdn form of the URLs, so in general, it seems safe and more transparent to include this form of the URL.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant