On Thu, Aug 03, 2000 at 02:55:19AM +0000, Sam Varshavchik wrote:
>
> The only thing I can possibly suggest is to try to change the filename
> extension of the attachment. The problem with MSIE 4.x was that it was
> discarding the MIME content-type it received from the server, and instead
> attempted to figure out the type of the server response based on the
> filename extension. Perhaps something similar is broken in MSIE 5.x as
> well.
>
> HTTP servers provide the MIME content-type of each response to HTTP
> clients, and that's what clients must use to figure out what to do with the
> response (render it as HTML, as plain text, or download the response if its
> content is unrecognized). Additionally even for known and understood MIME
> content-type, such as HTML, the MIME content-disposition can tell the HTTP
> client that the response should be saved in a file.
>
> The fact that MSIE ignores all these established standards, instead
> choosing to follow its own arkane and convoluted logic, from time to time,
> really shows contempt for established Internet protocols. I find it very
> distastesful. This isn't an accidental programming bug in MSIE. This is
> deliberate and willful ignorance of established standards. You can't screw
> up like this on accident. Back when they still didn't have much market
> share, I guess they had to fix MSIE to make it compliant with HTTP 1.x, now
> I suppose they are arrogant enough to feel that they can break it again.
There are two problems.
1. There is no standard MIME-type for forced "download"
2. MSIE is broken.
There are however remedies:
1. An unknown MIME-type forces Netscape to download
2. The MIME-type "application/ms-download" forces MSIE to download.
This means that using "application/ms-download" will do the trick. How evil
it might seem.
And about the MSIE broken-ness, I've put up a little interactive demo here:
Try it out yourself in NS _and_ MSIE: http://x42.com/test/mime/
/magnus
--
http://x42.com/
