Internet explorer и файлы .eml
Общие обсуждения
Все ответы
-
Вот мучались с той же проблемой, пишут что можно добиться нужного поведения с помощью octet-stream, только с ограничениями - OE использовать DDE и нужно отключить no cache
Проверьте еще раз правильность установки octet-stream, потому что у него поведение при смене mime-type изменяется :http://www.pcreview.co.uk/forums/thread-2691954.php
If the Content-type declared by the server is changed to
"application/octet-stream", MSIE presents a dialog box saying that the file
is an Outlook Express aplication, and asks me to choose among Open, Save or
Cancel. If I choose "Save", the operation works as expected; HOWEVER,
choosing "Open" only works if Outlook Express was NOT already running. If it
was, I get the error message (obviously misleading): "The file q.eml could
not be opened because it doesn't exist, or is being used by another
application (0x800CCF65, 2)".
Now, it is interesting to note that _exactly_ the same situation occurs if I
try to issue, at the command line, the command:
"C:\Program Files\Outlook Express\msimn.exe" /eml:q.eml
....which in a way makes sense, because this is the command associated by
Windows Explorer's "Tools -> Folder Options -> File Types" screen to the
Action "open" for .EML files.
On the other hand, the command:
start q.eml
....always works as it should (and as MSIE should, but does not), regardless
of whether OE was or not running.==
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 elsewhere: 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.IE5<random_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.
