mirror of
https://github.com/airmessage/airmessage-server.git
synced 2026-04-26 01:05:50 +03:00
[GH-ISSUE #17] Files with non-standard extension casing don't get picked up for automatic conversion #16
Labels
No labels
bug
enhancement
enhancement
pull-request
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/airmessage-server#16
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @jason919 on GitHub (Jul 7, 2022).
Original GitHub issue: https://github.com/airmessage/airmessage-server/issues/17
currently if the user sends an heic image, the web still shows the download sign, but it doesn't either display or download the image,
currently, no browser can actually support heic image yet, so we need a mechanism to automatically convert the heic to JPG
@tagavari commented on GitHub (Jul 8, 2022):
AirMessage Server should automatically convert .heic files to .jpeg for the web and Android clients, whenever they request to download an attachment.
I can confirm this by downloading this HEIC test file, sending it in a conversation, and then downloading that file from AirMessage for web. It gets converted to a .jpeg, and the web browser can display it. Are you finding that this is not the case?
@jason919 commented on GitHub (Jul 8, 2022):
not in my case, whenever other people share heic images to me, it shows the download icon, but it doesn't neither download or show image after I click. I attached the screenshots, someone shared 2 heic images to me, then I clicked the first one, it just shows a blank.
@jason919 commented on GitHub (Jul 8, 2022):
I used browser inspector, it shows it tried to access the image link like this: https://web.airmessage.org/28c372fc-7f19-41d7-8ea4-1cc209881efb, so how does it tell it is heic? the interesting thing is it shows http 200 back.
@jason919 commented on GitHub (Jul 8, 2022):
can you point me in the code where it does the conversion? Maybe I can fix the bug myself.
@tagavari commented on GitHub (Jul 8, 2022):
Thank you for the details.
FileNormalizationHelper.swift is what controls converting files from Apple's proprietary formats to more common ones.
Another place I would recommend to check is the server logs, which you can find at
~/Library/Application Support/AirMessage/logs/latest.log. Keep the log window open as you download an HEIC file, and you should see a message like this:@jason919 commented on GitHub (Jul 8, 2022):
checked the logs, it doesn't have any details. only got this:
2022-07-08 15-33-13 [info] Received new message: attachmentReq / of length 46
2022-07-08 15-33-27 [info] Received new message: attachmentReq / of length 46
@jason919 commented on GitHub (Jul 8, 2022):
I read the code, I think the problem is at this line 80 :
else {
return nil
}
It simply checks extension, but Apple may not have the extension for the heic, so the logic can be better with
ext == "heic" || exit == nil do the conversion. A smarter one shall use the image magic tool to do the conversion.
@jason919 commented on GitHub (Jul 8, 2022):
if my test server uses connect-open.airmessage.org, what's the link for web client?
@tagavari commented on GitHub (Jul 9, 2022):
I see, that makes sense. Your file isn't being picked up because the file extension is in capitals.
For now, the server should be updated to recognize file extensions in a case-insensitive manner. I've made these changes in this commit.
I agree that at some point this should be done in a more robust manner, perhaps by inspecting the file, or using the mime_type field that Messages provides.
I'm transferring this issue to airmessage-server.
Thank you so much for your help!
@tagavari commented on GitHub (Jul 9, 2022):
I do not have any pre-built site set up for connect-open.airmessage.org, though now that you bring it up it sounds like it might be a good idea. For now, you will have to build it from source.
@jason919 commented on GitHub (Jul 9, 2022):
i can build it from source, the config file is pointing to the connect-open.airmessage.org, how do I change it to point to the real server? The key file is also for the test server I believe.
@tagavari commented on GitHub (Jul 9, 2022):
The client secrets for the primary server are not publicly available. I ask that developers please do not connect unofficial clients to AirMessage's primary server.
My apologies for the inconvenience.
@jason919 commented on GitHub (Jul 9, 2022):
can you help release a beta for the fix?
@jason919 commented on GitHub (Jul 9, 2022):
another thing is, why is it designed to click the image to show? why not just show the images automatically?
@tagavari commented on GitHub (Jul 11, 2022):
I'll be able to prepare a release with this fix this week.
Having attachments automatically show up is something I'd love to have. There's no strict reason as to why it's not implemented, though compression or automatic conversions make this a little trickier.
@jason919 commented on GitHub (Jul 11, 2022):
@tagavari commented on GitHub (Jul 11, 2022):
The issue with this approach is that it can take up a lot of bandwidth and data if users aren't prepared for it.
AirMessage for Android has this functionality, though it's a fairly simple implementation that downloads small files as you scroll by them.
@jason919 commented on GitHub (Jul 11, 2022):
I think you worry about it too much. The folks who want to use this App are geeks. Their gadgets and network speed shall be more than enough to handle this tiny traffic.
One thing you can do to reduce your main website traffic is to cache the images on the client side longer, so you can set the image expiration header really long in http header, so web client won't download images every time from server.