-
-
Notifications
You must be signed in to change notification settings - Fork 319
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
Default content-type should not be application/octet-stream #139
Comments
In case returning null is not acceptable for backward compatility reasons,
|
In a standard point of view, here the rules:
So unknown type => no |
Fix broofa#139 Default content-type should not be application/octet-stream
+1 This would help me as well. |
Fixed in |
Fixes webpack#354 * Only set 'Content-Type' header if mime type is known. * Remove testing for 'Content-Type' of unknown types. * Do not test against `application/octet-stream'. Unknown media types should have content-type blank. Because frameworks handle Content-Types differently, it is not possible to standardize testing at the moment. Tests against `application/octet-stream` can create false positives with Express because of this. https://tools.ietf.org/html/rfc7231#section-3.1.1.5 broofa/mime#139
application/octet-stream
is not a neutral content-type. When used in theContent-Type
header of an http response, it may trigger download (and possibly execution).On top of being an unwanted behavior in most cases, this is a security issue.
In case of serving files uploaded by users, It may allow them to makes visitors download virus and malwares without them knowing it (depending on the browser/download manager, the download could be hardly noticeable). Some OS/browser combination may also execute it or propose to execute it.
Also, assuming a file (or directory) is a binary file just because it has an unknwon extension is totally wrong and an unexpected behavior.
The expected and optimal behavior is to return null when the content type could not be guessed.
We've discussed a bit on the subject here: pillarjs/send#98
The text was updated successfully, but these errors were encountered: