Unknown file type MIME?

Question

Do I have to specify a MIME type if the uploaded file has no extension? In other words is there a default general MIME type?

Solution 1

You can use application/octet-stream for unknown types.

RFC 2046 states in section 4.5.1:

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

Solution 2

RFC resources:

We should use RFC-7231 (HTTP/1.1 Semantics and Content) as reference instead of RFC-2046 (Media Types) because question was clearly about HTTP Content-Type.

Also RFC-2046 does not clearly define unknown types but RFC-7231 does.

Short answer:

Do not send MIME type for unknown data.
To be more clear: Do not use Content-Type header at all.

References:

RFC-7231
Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
3.1.1.5. Content-Type

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.

That section clearly tells you to leave it out if you don't know it for sure. It also tells that receiver could assume that type is application/octet-stream but thing is that it might also be something else.

What's different then?

RFC-2046
4.5.1. Octet-Stream Subtype

The recommended action for an implementation that receives an
"application/octet-stream" entity is to simply offer to put the data
in a file, with any Content-Transfer-Encoding undone, or perhaps to
use it as input to a user-specified process.

And, as already stated above:

RFC-7231
3.1.1.5. Content-Type

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.

Conclusion:

If you define it as "application/octet-stream" then you are telling that you know that it is "application/octet-stream".

If you don't define it then you are telling that you don't know what it is and leave decision to receiver and receiver could then check if it walks like duck and...

Solution 3

I prefer application/unknown, but result will be surely the same as application/octet-stream

Comments

[Sampo Sarrala - codidact.org]

Actually, per RFC's you should not send any type information with unknown data. RFC-2046 defines only known types but RFC-7231 tells you how to handle unknown types.

[Jpnh]

@SampoSarrala I read RFC-7231 a little differently: "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." I interpret that as we should either send NO Content-Type or we are safe to send application/octet-stream as a default if we do not want clients playing guessing games with content examination.

[Sampo Sarrala - codidact.org]

@Jpnh Yes, that's right. Content-Type header should not be present whenever it is unknown. One could also send application/octet-stream which basically tells client that "you don't want to display it just now, but go on and save these bytes to file instead". This makes web clients offer saving file. Option 1 == Don't know anything about this file. Option 2 == File contents can't be described using mime or it should only be saved to disk. In practice either option would be correct. I should have chosen better wording to avoid confusion.

[FF_Dev]

This answer deserve upvote as it is the only in the truth. Additionally Using "application/octet-stream" by default make most browser trigger download which is a security hole considering the almost invisible modern download managers.

[FF_Dev]

"Arbitrary binary data" is not "unknown". By using application/octet-stream you tell to the browser that the content type is known, is not text nor an image but arbitrary binary data and as a result should be downloaded to file and possibly executed. On top of being wrong, this is a security hole, especially considering barely visible modern download managers. The right answer is no content-type header. If you don't know which kind of file it is, the browser may know it so let it guess, especially when it known the context of use (image, document, script, ...)

[tripleee]

This is correct for HTTP, but the question is about MIME in general, not about HTTP. In email, for example, the rules are completely different. See also discussion at proposed duplicate stackoverflow.com/questions/12539058/…

[Mark Amery]

@FF_Dev I'm sure that's nonsense. "Arbitrary binary data" does not imply "executable"; there's no reason a browser (or download manager) should assume an application/octet-stream file is executable. And even if a browser is knowingly downloading an executable file, it doesn't "possibly execute" it without the user asking to; merely downloading an executable doesn't imply that I want it executed right now. If there's really a browser that may execute application/octet-stream files automatically on download, tell us which, and how to reproduce the behaviour. Right now I don't believe you.

[FF_Dev]

@Mark Amery I have not said the browser would execute the threat itself. But with this server behavior I may makes you download an executable file just from an image tag without you notice it. Then if the executable file is faking the name and icon of a legacy executable you can execute it by yourself.

[Mark Amery]

@FF_Dev That argument doesn't make any sense. For one thing, your ability to execute a downloaded file is unrelated to the Content-Type it was served with; that information doesn't get stored anywhere when you download a file. For another, application/octet-stream doesn't imply that the file is executable in the first place.

[FF_Dev]

@Mark Amery you're right but my security concern was on the ability to makes you download something from an image tag which is not an expected behavior and may lead to security issues on website when users can upload files used as images. Please note that this is a theorical issue that have been already prevented in many browsers. The issue here is that there is a conflict between Content-Type and HTML RFC. What the browser should do in this case in not clearly defined.

[FF_Dev]

It may lead to unexpected behavior like browser downloading a svg file because server don't know about svg file and tell through content type "I know what it is, it's arbitrary binary data" (that's what application/octet-stream say)

[Mark Amery]

@FF_Dev "there is a conflict between Content-Type and HTML RFC" - leaving aside pedantics (HTML has not been specified by an RFC for many years), what conflict are you talking about, and how is it relevant? What passages from tools.ietf.org/html/rfc7231#section-3.1.1.5 and html.spec.whatwg.org contradict each other, and what does that have to do with whether a browser saves the file targeted by an img to disk or not?

[FF_Dev]

@Mark Amery Conflict is a wrong word. Hole is the good one. HTML spec define that images with unsupported MIME Types have to be aborted but let the User-agent (i.e. browser) guess about what mime types are supported and how to open/display this image. On the other hand, Mime RFC tools.ietf.org/html/rfc2046#section-4.5.1 define that application/octet-stream should be proposed to be saved to a file (i.e. downloaded). The browser impl is free to use OS registered applications to guess if this MIME type is supported and "open" the image or to open it in its own download manager.

[justdan23]

I gave an uptick for the same reason, however I agree with FF_Dev. Unless intent is to be "application/octet-stream" and to trigger a download, there is a need for "application/unknown". It would be nice if the browsers would not try to download the file if the "Content-Disposition" wasn't set, but there are too many web sites haphazardly downloading files without setting their filename to use. Especially banks.

[tripleee]

RFC-7231 and the entire discussion around that is specific to the HTTP protocol. The question here does not mention HTTP at all. At a minimum, this discussion here in the comments should make clear that it's about what's correct per HTTP specifications, and tangential or even irrelevant from the perspective of MIME itself.