Skip to content

Fix documents arriving as unnamed .bin files (mime type + FileName) - #328

Open
NahumLitvin wants to merge 1 commit into
lharries:mainfrom
NahumLitvin:fix-document-mime-filename
Open

Fix documents arriving as unnamed .bin files (mime type + FileName)#328
NahumLitvin wants to merge 1 commit into
lharries:mainfrom
NahumLitvin:fix-document-mime-filename

Conversation

@NahumLitvin

Copy link
Copy Markdown

Fixes #327.

I hit this sending a PDF to my wife: it arrived on her phone as an unnamed .bin with no preview. Two things cause it: the extension switch falls through to application/octet-stream for anything that isn't a known image/audio/video type, and DocumentMessage is built without FileName, which mobile clients use for the displayed name and extension.

This is the minimal fix: resolve the mime type with the stdlib (mime.TypeByExtension), keeping octet-stream only as the empty-lookup fallback, and set FileName next to Title. 7 lines. Verified on my own bridge — the same PDF now arrives named, with the right icon and preview, on iOS and Android.

I know #157, #199, #236, #243 and #316 touch the same area; this one is just the smallest diff that fixes the reported behaviour, in case that's easier to review. Happy to close it in favour of any of those.

Two gaps made every send_file document render as an unnamed .bin on
recipients' phones:

- unknown extensions fell through to application/octet-stream; now the
  mime type is resolved with the stdlib mime.TypeByExtension, keeping
  octet-stream only as the last-resort fallback
- DocumentMessage carried Title but no FileName, and WhatsApp mobile
  clients use FileName for the displayed name and extension

Fixes lharries#327
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 this pull request may close these issues.

Documents sent via send_file arrive as unnamed .bin files (missing mime type + FileName)

1 participant