Unknown file type MIME?

mime mime-types default-value

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?

Bombe

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.

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.

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

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

Community

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

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.

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/…

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.

Lada

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

Is there a standard which allows using application/unknown instead of application/octet-stream?

Thanks! application/unknown is working great, octet-stream results an error in chrome at my sample png-file!

Why serve a .png file as application/octet-stream or application/unknown? There's a reason they invented image/png.

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

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 to skip any executing :/

Unknown file type MIME?

Follow WeChat

Want to stay one step ahead of the latest teleworks?

相似问题

Platform

Support

Links

Contact US