174

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?

Shimmy Weitzhandler
  • 101,809
  • 122
  • 424
  • 632

3 Answers3

218

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.

Bombe
  • 81,643
  • 20
  • 123
  • 127
  • 4
    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. – Sampo Sarrala - codidact.org Feb 22 '15 at 17:31
  • @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. – Jpnh Mar 19 '15 at 20:30
  • 1
    @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. – Sampo Sarrala - codidact.org Mar 20 '15 at 07:57
  • 5
    "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, ...) – FF_Dev Mar 01 '16 at 11:54
  • 1
    @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. – Mark Amery Aug 10 '18 at 11:23
  • @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. – FF_Dev Aug 11 '18 at 17:26
  • @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. – Mark Amery Aug 12 '18 at 13:33
  • @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 Aug 13 '18 at 14:12
  • 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) – FF_Dev Aug 13 '18 at 14:16
  • @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 https://tools.ietf.org/html/rfc7231#section-3.1.1.5 and https://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? – Mark Amery Aug 15 '18 at 11:09
  • @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 https://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. – FF_Dev Aug 16 '18 at 08:50
  • 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. – tripleee Jul 17 '19 at 13:17
57

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...

Community
  • 1
  • 1
Sampo Sarrala - codidact.org
  • 4,770
  • 2
  • 25
  • 45
  • 1
    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 Mar 01 '16 at 11:40
  • 1
    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 http://stackoverflow.com/questions/12539058/is-there-a-default-mime-type – tripleee May 26 '16 at 14:40
  • 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. – justdan23 May 15 '19 at 15:35
18

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

Lada
  • 221
  • 2
  • 2
  • 19
    Is there a standard which allows using application/unknown instead of application/octet-stream? – Hendrik Brummermann May 21 '11 at 20:31
  • 3
    Thanks! application/unknown is working great, octet-stream results an error in chrome at my sample png-file! – fnkr May 12 '13 at 13:34
  • 11
    Why serve a .png file as `application/octet-stream` or `application/unknown`? There's a reason they invented `image/png`. – Aidiakapi Apr 24 '14 at 00:40
  • 1
    Why reinvent the wheel @Aidiakapi? Send it unknown and let the browser & os do their jobs. – jenson-button-event Jan 03 '15 at 20:37
  • 10
    @jenson-button-event It has nothing to do with reinventing the wheel. The MIME type specifies your intent. If you know that what you're sending is supposed to be a png image, pass that information along. If the bytes accidentally represent a jpeg, your application can warn you that it's not a valid png, and that you have a bug somewhere else. In addition, not all applications are as robust and fault-tolerant as a browser. They're designed to fix the programmer's mistakes, but that is nowhere near it's only purpose. A browser's not the only application using MIME types. – Aidiakapi Jan 03 '15 at 20:44
  • hmm, i prefer convention. if it syas .png at the end its a png sure if i wanted to send a pdf with a .png extension i might specify the MIME type – jenson-button-event Jan 03 '15 at 22:52
  • @Aidiakapi If you know it's a png, then it's easy to send it as `image/png`. The problem is when you don't really know what type it is, for example if you're integrating with a system that doesn't provide this information in a good format or with user uploads that can be any file type. – Svish Apr 15 '15 at 12:18
  • 1
    @Svish If you have no idea as to what data you're sending (arbitrary third party data) then you should omit the MIME type. If you know for example that the data you're sending is an image, you can test if it is one of the popular image formats and send that MIME type. If it's a less common image type like say a HDR `exr` file, most media you're going to interface with isn't going to be able to handle it anyways. – Aidiakapi Apr 15 '15 at 13:08
  • 1
    @Svish Long story short. `application/octet-stream` is for application specific data, not for when you don't know what the data represents. Omitting the MIME type tells the target to find out how to parse it itself. All with all, if you don't know it, and don't want to make an effort to get to know it, just don't send MIME types. It's all about communication and interfacing, not about 'the browser can figure it out'. Yes it can, but it shouldn't have to unless you tell it to. – Aidiakapi Apr 15 '15 at 13:10
  • @Aidiakapi That I agree with. It just didn't seem like you got the problem to begin with, but guess you did :) – Svish Apr 15 '15 at 13:36
  • 3
    What's your reference? the unknown type is not contributing any information regarding the content or state of the file, or even if it is binary or text based, it is too obscure for production code, might be ok for a small project, since if a file mimetype has no handler in the OS, it is essentially a downloadable binary- and the *unknown* type is a known handle in windows OS, which you can assign an action (for example opening unknown files with notepad). Although bad practice you can use the unknown type combined with [this](http://stackoverflow.com/a/34758866/257319) to skip any executing :/ –  Jan 13 '16 at 06:23
  • I like the idea of using "application/unknown" in cases where you want to indicate something at least tried to type it vs "no Content-Type" indicating a data integrity issue. A web page can decide whether to fallback to "application/text" so the source media doesn't pretend to be something it isn't. – justdan23 May 15 '19 at 15:26