in reply to PHP to CGI

You have already answered your own question! Adjust the mime-type to something other than is configured on the windows client by default and it will force a download.

The key to the open/download issue is the difference in the way that IE deals with mime-types. When your Perl app returns content, IE has no choice but to believe the mime-type header supplied. IE compares the mime-type supplied in the content header and acts according to the settings for that mime-type.

Your application (e.g. /myapp/download.cgi?file1) returns a file (stream of bytes) which just happens to be a Word document:

  1. Setting the Content-type header to application/msword will cause IE to recognise the stream of bytes as a Word document and take the default action. This is probably loading it up in the same window
  2. Setting the mime-type to application/msword-download will cause IE to look for information relating to the application/msword-download mime-type and take action accordingly. Since there is no mime-type information set, IE will take the default action of asking you to save or open the file.
The mime-type / content / action relationship is configured in the registry of the Windows client. The HKCR/.extension keys map the mime-type to a document extension.
HKCR\.doc "Content Type"="application/msword"

Replies are listed 'Best First'.
Re: Re: PHP to CGI
by hardburn (Abbot) on Mar 31, 2004 at 15:16 UTC

    IE has no choice but to believe the mime-type header supplied

    Actually, IE tends to ignore MIME types whenever it bloddy well feels like it. Which is a big problem, because server admins sometimes set everything to a default MIME type of 'text/plain', even though they are returning HTML, but IE DWIMs it to parsing the HTML. This will look fine to the people using IE, but browsers which correctly obey the MIME type will display the HTML as text. It's even worse when binary files are being sent as plaintext.

    ----
    : () { :|:& };:

    Note: All code is untested, unless otherwise stated