bug: Failing to download opengraph attachments causes the entire preview request to fail #2437

New issue

Open

opened 2026-11-02 01:15:53 +00:00 by nex · 1 comment

nex commented

2026-11-02 01:15:53 +00:00

Owner

What is the bug?

When scraping opengraph tags, continuwuity tries to download any images/videos/audio attachments specified in the metadata. However, if one of those downloads fails, the entire preview is aborted. This is undesirable in my situation because continuwuity is unable to download an image in a URL I previewed, but it can still include all other data, but instead it just returns nothing.

Steps to reproduce

Make a website that serves HTML when requested
Include an og:image in the metadata, and point it at a URL that doesn't exist or otherwise rejects the request
Make a URL preview request targeting that website
Observe as continuwuity fails to download the image and in turn gives up the entire request.

Server name and version

nexy7574.co.uk v26.9.1 f3d8e8d688

Additional context

An example of this would be my fediverse server, which serves notes that continuwuity fetches just fine, but rejects unauthenticated media proxy requests (for obvious reasons) for things like avatars and attachments with a 404. For example, https://fedi.transgender.ing/notes/aprgloxpdima52mv.

The network logs look like this:

[26-11-02 01:14:23] 200 HTTP/2.0 HEAD   /notes/aprgloxpdima52mv: 0.0KiB in 0.03s from continuwuity/26.9.1+9a880ab26,b=nex/mods (embedbot; facebookexternalhit/1.1; +https://continuwuity.org) (no auth) @ 82.1.180.57
[26-11-02 01:14:24] 200 HTTP/2.0 GET    /notes/aprgloxpdima52mv: 17.9KiB in 0.04s from continuwuity/26.9.1+9a880ab26,b=nex/mods (embedbot; facebookexternalhit/1.1; +https://continuwuity.org) (no auth) @ 82.1.180.57
[26-11-02 01:14:24] 404 HTTP/2.0 GET    /proxy/avatar.webp?url=https%3A%2F%2Fmedia.d.on-t.work%2Fnotbdw%2Fpublic-ab6e426c-f2d5-468b-a466-6c524d202a56.webp&avatar=1: 0.0KiB in 0.00s from continuwuity/26.9.1+9a880ab26,b=nex/mods (embedbot; facebookexternalhit/1.1; +https://continuwuity.org) (no auth) @ 82.1.180.57

And I suspect this ? is causing that error to be propagated directly:

	`if let Some(obj) = html.opengraph.images.first() {`
	`preview_data = self.download_image(&obj.url, Some(preview_data)).await?;`
	`}`

For repro, this is how /proxy/avatar.webp is serving a 404, since that isn't standard functionality of the underlying server (caddy config):

fedi.transgender.ing {
        # ...
        @no_sec_proxy {
                not header Sec-Fetch-Dest image
                not header Sec-Fetch-Mode no-cors
                not header Sec-Fetch-Site same-origin
                not header Referrer https://fedi.transgender.ing/
                path /proxy/*
        }
        respond @no_sec_proxy 404
        # ...
}

### What is the bug? When scraping opengraph tags, continuwuity tries to download any images/videos/audio attachments specified in the metadata. However, if one of those downloads fails, the entire preview is aborted. This is undesirable in my situation because continuwuity is unable to download an image in a URL I previewed, but it can still include all other data, but instead it just returns nothing. ### Steps to reproduce 1. Make a website that serves HTML when requested 2. Include an `og:image` in the metadata, and point it at a URL that doesn't exist or otherwise rejects the request 3. Make a URL preview request targeting that website 4. Observe as continuwuity fails to download the image and in turn gives up the entire request. ### Server name and version nexy7574.co.uk v26.9.1 f3d8e8d688ca7ca66f2e8bba2a2a6fcc65af2aaf ### Additional context An example of this would be my fediverse server, which serves notes that continuwuity fetches just fine, but rejects unauthenticated media proxy requests (for obvious reasons) for things like avatars and attachments with a 404. For example, https://fedi.transgender.ing/notes/aprgloxpdima52mv. The network logs look like this: ``` [26-11-02 01:14:23] 200 HTTP/2.0 HEAD /notes/aprgloxpdima52mv: 0.0KiB in 0.03s from continuwuity/26.9.1+9a880ab26,b=nex/mods (embedbot; facebookexternalhit/1.1; +https://continuwuity.org) (no auth) @ 82.1.180.57 [26-11-02 01:14:24] 200 HTTP/2.0 GET /notes/aprgloxpdima52mv: 17.9KiB in 0.04s from continuwuity/26.9.1+9a880ab26,b=nex/mods (embedbot; facebookexternalhit/1.1; +https://continuwuity.org) (no auth) @ 82.1.180.57 [26-11-02 01:14:24] 404 HTTP/2.0 GET /proxy/avatar.webp?url=https%3A%2F%2Fmedia.d.on-t.work%2Fnotbdw%2Fpublic-ab6e426c-f2d5-468b-a466-6c524d202a56.webp&avatar=1: 0.0KiB in 0.00s from continuwuity/26.9.1+9a880ab26,b=nex/mods (embedbot; facebookexternalhit/1.1; +https://continuwuity.org) (no auth) @ 82.1.180.57 ``` And I suspect this `?` is causing that error to be propagated directly: https://forgejo.ellis.link/continuwuation/continuwuity/src/commit/f3d8e8d688ca7ca66f2e8bba2a2a6fcc65af2aaf/src/service/media/preview.rs#L299-L301 For repro, this is how `/proxy/avatar.webp` is serving a 404, since that isn't standard functionality of the underlying server (caddy config): ```caddyfile fedi.transgender.ing { # ... @no_sec_proxy { not header Sec-Fetch-Dest image not header Sec-Fetch-Mode no-cors not header Sec-Fetch-Site same-origin not header Referrer https://fedi.transgender.ing/ path /proxy/* } respond @no_sec_proxy 404 # ... } ```

nex added the

labels

2026-11-02 01:15:53 +00:00

nex commented

2026-11-02 01:24:21 +00:00

Author

Owner

{"errcode":"M_UNKNOWN","error":"Failed to fetch URL preview: Unknown: Image download returned HTTP 401 Unauthorized sender_user=@nex:nexy7574.co.uk url=https://fedi.transgender.ing/notes/aprgloxpdima52mv"}

The response does indeed indicate that the entire request was aborted (the error was changed as I was testing something else, but that's not relevant)

``` {"errcode":"M_UNKNOWN","error":"Failed to fetch URL preview: Unknown: Image download returned HTTP 401 Unauthorized sender_user=@nex:nexy7574.co.uk url=https://fedi.transgender.ing/notes/aprgloxpdima52mv"} ``` The response does indeed indicate that the entire request was aborted (the error was changed as I was testing something else, but that's not relevant)

nex added

and removed

labels

2026-11-02 01:24:25 +00:00

nex referenced this issue from a pull request that will close it,

2026-11-03 19:19:58 +00:00

fix: Don't fail entire preview requests when auxiliary requests fail #2448