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

Content type from file, not from extension #1839

Open
mbrevda opened this issue Apr 9, 2024 · 3 comments
Open

Content type from file, not from extension #1839

mbrevda opened this issue Apr 9, 2024 · 3 comments
Assignees
Labels
feature request Feature request: request to add new features or functionality

Comments

@mbrevda
Copy link

mbrevda commented Apr 9, 2024

#155 introduced automatically setting contentType based on the file suffix. I was wondering about this design: wouldn't it be more accurate to check the file contents by, say, checking the checking the magic numbers signature and only falling back to go's (arguably quite limited) list of extensions if a proper mime type cannot be found?

Here is an example of a golang lib with quite an extensive list of files detected. The ubiquitous file command might be helpful, too.

@sethiay sethiay assigned marcoa6 and unassigned marcoa6 Apr 18, 2024
@raj-prince raj-prince self-assigned this Apr 18, 2024
@raj-prince
Copy link
Collaborator

Thanks @mbrevda for the suggestion!!

I can understand this might make the content-type more accurate. But based on usage it seems like existing implementation is sufficient.

Do you have any requirement which is not full-filled by the existing implementation? If you could provide, this might help in understanding the use-case and accordingly help in prioritizing this.

Thanks!!

@mbrevda
Copy link
Author

mbrevda commented Apr 19, 2024

There are a couple of use cases where the current implementation can be improved:

  • unknown file extensions (the current list is relatively short)
  • Missing file extensions
  • Intentionally misleading file extensions

The last one may be security-related as the current implementation relies on user-supplied input, breaking the cardinal "never trust user input" rule

@raj-prince raj-prince added the feature request Feature request: request to add new features or functionality label Apr 29, 2024
@raj-prince
Copy link
Collaborator

Thanks @mbrevda for the suggestion! We have discussed internally and decided to track it as feature request.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request Feature request: request to add new features or functionality
Projects
None yet
Development

No branches or pull requests

3 participants