Handling application/octet-stream

1997-08-27 19:02:53
MHonArc List,

The following is a message from the comp.mail.mime newsgroup.
I think it is appropriate with the current discussion about
setting the right MIME types in mail messages and potential
problems using heuristics to getting around mis-typed data.

--- Begin Message ---
Jamie> Jamie W. Zawinski <URL:mailto:jwz(_at_)netscape(_dot_)com>

Jamie> In <URL:news:34034BA7(_dot_)A30D711(_at_)netscape(_dot_)com>, Jamie 

Jamie> Another bug in IE is that it always sends out attachments with
Jamie> Content-Type application/octet-stream: and this works fine for
Jamie> them, because they ignore the Content-Type and just look at the
Jamie> extension.  In self defense, I made Netscape look at the file
Jamie> extension in preference to the Content-Type if and only if the
Jamie> Content-Type is application/octet-stream.  I absolutely hate
Jamie> that I had to do this.

Why do you hate it?  I think it is a perfectly reasonable handler for
application/octet-stream (as a default - I assume you respect the
user's preference if different).  After all, octet-stream is basically
saying, "I'm not being specific about this; do what you like with it."

No, that's not what application/octet-string says.

Application/octet-stream says, "here is a sequence of octets, don't
assume anything more about it".

Using the filename of an application/octet-stream content to govern
how that content is displayed potentially exposes one to a large
number of security holes -- especially if the mechanism used to choose
the presentation method blindly uses the local system's file extension

The policy for the presentation of incoming email attachments needs to
be very different than that for local file system objects.  Otherwise,
every application you have installed on your system becomes yet
another security hole.


--- End Message ---
<Prev in Thread] Current Thread [Next in Thread>