-
Notifications
You must be signed in to change notification settings - Fork 425
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
Comments
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!! |
There are a couple of use cases where the current implementation can be improved:
The last one may be security-related as the current implementation relies on user-supplied input, breaking the cardinal "never trust user input" rule |
Thanks @mbrevda for the suggestion! We have discussed internally and decided to track it as feature request. |
#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.The text was updated successfully, but these errors were encountered: