Image download links #51
Conversation
|
Thank you for you contribution. I like the direction you are going here and have a few comments and thoughts. |
meshchat
Outdated
| if ext == "jpg" or ext == "jpeg" then | ||
| content_type = "image/jpeg" | ||
| elseif ext == "png" then | ||
| content_type = "image/png" | ||
| elseif ext == "gif" then | ||
| content_type = "image/gif" | ||
| else | ||
| print("Content-Disposition: attachment; filename=\"" .. file .. "\";\r") | ||
| content_type = "application/octet-stream" | ||
| end |
There was a problem hiding this comment.
While this is a good first start, I am thinking that it might be more beneficial to start to introduce full MIME type support. Take a look at https://github.com/lunarmodules/lua-mimetypes. By using lua-mimetypes a lot more file formats can be supported and shorten this to just a couple of lines.
There was a problem hiding this comment.
I would counter with: "application/octet-stream" does handle all filetypes correctly, PDFs, ZIPs, EXEs, etc. (Because it downloads it and at that point, it's up to your computer to decide what to do with it.) And even if lua-mimetypes were included, you'd still need to conditionally allow through images as non-attachments, if you wanted them in a browser window and not downloaded. Also, in the small memory environment, this is a few lines of code, but lua-mimtypes is 300 or so more lines and doesn't cover the ~2,000 lines in a type Linux system. (/etc/mime.types)
I am happy to do it either way though.
There was a problem hiding this comment.
I've added more image mime types from lua-mimetypes. I'm not sure what it would add to include other mime types when application/octet-stream has been handling those fine.
2 participants
I've made a few changes to my meshchat:
(I access my AREDN node in an odd way sometimes and using an absolute link instead of a relative link makes assumption about DNS resolution when I'm using the IP.)