Unknown file type MIME?
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.
I prefer application/unknown
, but result will be surely the same as application/octet-stream
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-TypeA 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 SubtypeThe 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-TypeIf 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...