sohogenerous

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

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.

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.

+1 This would help me as well.

Fixed in v2