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

Default content-type should not be application/octet-stream #139

Closed
felicienfrancois opened this issue Jan 24, 2016 · 4 comments
Closed
Labels

Comments

@felicienfrancois
Copy link

application/octet-stream is not a neutral content-type. When used in the Content-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

@felicienfrancois
Copy link
Author

In case returning null is not acceptable for backward compatility reasons,

  • text/plain would be a better default on the web for security reasons (the content will never be downloaded nor executed)
  • application/unknown could be also a good default because it is less handled specifically by browsers (not downloaded) and it also allow to handle it server side because this is not the type of another known file.

@felicienfrancois
Copy link
Author

In a standard point of view, here the rules:

  • RFC-2046 which defines only known types

The "octet-stream" subtype is used to indicate that a body contains arbitrary binary data.

  • RFC-7231 which tell what to do when the type is unknown

A sender that generates a message containing a payload body SHOULD
generate a Content-Type header field in that message unless the
intended media type of the enclosed representation is unknown
to the
sender. If a Content-Type header field is not present, the recipient
MAY either assume a media type of "application/octet-stream"
([RFC2046], Section 4.5.1) or examine the data to determine its type.

So unknown type => no Content-Type header.

felicienfrancois added a commit to felicienfrancois/node-mime that referenced this issue Mar 1, 2016
Fix broofa#139 Default content-type should not be application/octet-stream
@wamoyo
Copy link

wamoyo commented Mar 23, 2017

+1 This would help me as well.

@broofa
Copy link
Owner

broofa commented Sep 15, 2017

Fixed in v2

@broofa broofa closed this as completed Sep 15, 2017
clshortfuse added a commit to clshortfuse/webpack-dev-middleware that referenced this issue Jan 1, 2021
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants