Downloading with MSIE and opening with OE .EML files doesn't work: SOLVED!
 

OK, it turned out that the problem was not specific to Outlook Express, and
the inability by OE to open .eml files whose names were passed with the
"/eml:" command line switch was a red herring: OE _can_ open them, but they
must be passed complete with their (absolute) path, because apparently OE
changes the current directory to %HOMEPATH% (\Documents and
Settings\%USERNAME%) _before_ parsing the arguments (booo!), so a file
passed with a relative path is not found within the directory that was the
current one when the command was issued.

But as I said, the problem lied elsewhe namely, in the "Cache-control:
no-cache" HTTP header sent by my webserver. It appears that MSIE takes a
fundamentalist approach to compliance with it, and deletes the downloaded
file from the cache (%HOMEPATH%\Local Settings\Temporary Internet
Files\Content.IE5random_subdir ) immediately after completing the
download, without even giving the helper application associated with the
filename a fighting chance to grab it... Replacing the "no-cache" parameter
with something less harsh, such as "max-age=120", fixed the malfunction.

It still remains necessary to use a content-type "application/octet-stream"
in order to prevent MSIE from opening the document in its own window as
MHTML, but that's a minor annoyance.

Anyway, many thanks to all who kindly posted followups to this thread!

Enzo

Downloading with MSIE and opening with OE .EML files doesn't work: SOLVED!
 

Thanks for the followup and the info. I won't ask how long it took you to
figure all that out. VBG

steve

"Enzo Michelangeli" wrote in message
...
OK, it turned out that the problem was not specific to Outlook Express,
and
the inability by OE to open .eml files whose names were passed with the
"/eml:" command line switch was a red herring: OE _can_ open them, but
they
must be passed complete with their (absolute) path, because apparently OE
changes the current directory to %HOMEPATH% (\Documents and
Settings\%USERNAME%) _before_ parsing the arguments (booo!), so a file
passed with a relative path is not found within the directory that was the
current one when the command was issued.

But as I said, the problem lied elsewhe namely, in the "Cache-control:
no-cache" HTTP header sent by my webserver. It appears that MSIE takes a
fundamentalist approach to compliance with it, and deletes the downloaded
file from the cache (%HOMEPATH%\Local Settings\Temporary Internet
Files\Content.IE5random_subdir ) immediately after completing the
download, without even giving the helper application associated with the
filename a fighting chance to grab it... Replacing the "no-cache"
parameter
with something less harsh, such as "max-age=120", fixed the malfunction.

It still remains necessary to use a content-type
"application/octet-stream"
in order to prevent MSIE from opening the document in its own window as
MHTML, but that's a minor annoyance.

Anyway, many thanks to all who kindly posted followups to this thread!

Enzo