Internet Explorer 10 and MHT files. RRS feed

  • Question

  • Greetings everyone,

    I noticed there are already a lot of topics about MHT files and Internet Explorer, but they concern IE 9.  My problem happens with IE 10.

    We have an Apache server here (on Windows 2003) hosting MHT files which users should see in their browser.

    It works alright on our machines with IE 8 and IE 9, but we have problems with IE10: the files are rendered "raw", you see all the text code but not the "rendered" content with images, fonts, styles, etc.

    From the same computer, I tried the following browsers, with the corresponding results:

    • Firefox 19.0.2: cannot open MHT files. Asks me if I want to open it with IE, and it opens a local copy located on C:\Users\[my login]\AppData\Local\Temp\ - works, with IE10!  -OK
    • Opera 12.02: opened directly in the browser -OK
    • Google Chrome 25.0.1364.152, same as Firefox except the copy is located in the Downloads library -OK
    • Internet Explorer 10.0.9200.16438: displays the raw file -NOT OK

    On 2 other PCs then, I tried

    • Internet Explorer 9.0.8112.16421 and it went perfectly -OK ! 

    Conclusion seem to indicate that IE 10 *can* render MHT file, but not directly from a web server.  I suspect some kind of "security upgrade" which blocks the rendering, but can't get to figure out which one.

    Note: the website is internal, is in the Intranet security zone, and the proxy is bypassed for these.


    Monday, March 11, 2013 3:04 PM

All replies

  • Hi,

    IE10 standards mode (and IE10 'Quirks' mode) does not support xml data islands.

    MHT files contain the Mark of the Web which restricts what external links and resources are packaged with the MHT.

    MHT are compressed... see this IE Internals Post...


    the mime-type or mht is message/rfc822

    IE security zone settings has one for mime-type sniffing.



    Monday, March 11, 2013 11:22 PM
  • Thanks for your answers guys.

    @idle curiosity:  I tried your link, and it displays correctly in my IE 10.0.9200.16438, without any flickering or problem.   So maybe the MHT files we have are badly coded?    Here is a sample : http://shar.as/JSgIp  , still doesn't display correctly in browser while your do.

    @IECustomizer: I have defined the message/rfc822 mime type to be applied to EML, MHT and MIME (like explained in various other topics on the matter), but it doesn't help :(


    Tuesday, March 12, 2013 10:14 AM
  • So maybe the MHT files we have are badly coded?    Here is a sample : http://shar.as/JSgIp  , still doesn't display correctly in browser while your do.

    I suspect a difference in Content-Type header.   So try using the Security setting  which avoids "MIME Sniffing"...

    idle curiosity's Wiki example:

    No Content-type header?   So MIME Sniffing must be being done.

    Your sample:

    Content-Type text/plain; charset=ISO-8859-15

    So it is rendered as Text.

    Now I have disabled MIME Sniffing and used Ctrl-F5 to refresh both tabs.   The only difference is that now the Wiki produces a warning message about its content?   Strangely the error messages in the Console tab are unchanged?  YMMV.

    Looking at the source a different charset is being used by each.   UTF-8 for the Wiki and  "Windows-1252"  for Quoted-Printable for the other.   One problem might be the transport encoding.   E.g. how well do ISO-8859-15 and Windows-1252 match?  And are those accented characters allowed in both?

    Can you try removing your Content-type: header?



    Robert Aldwinckle

    Tuesday, March 12, 2013 5:34 PM
  • the 'link' is hosted on google docs...

    the response is redirected to mhtml:https://doc-04-98-docs.googleusercontent.com/docs/securesc/qi5hsc6uu2i3a97ah1j7f2qgromm3dnu/rj0c0tb7j0letkiof31m0fmiddfj7snr/1363125600000/14661592657844749615/05044824918366842307/0B8BLd2qPPV7XVjM1ZU9VQ0ZDaGs?nonce=s1kis7ls3esh6&user=[removed]&hash=177nip3trhe4fdc17icerag36vq7fjmv

    which has a mime-type of application/x-mimearchive


    Tuesday, March 12, 2013 11:40 PM
  • I patched into Bixessss' RESPONSE header, replacing its Content-Type: text/plain with the following, and it works.  The mht displays like it should:

       Content-Type: message/rfc822; charset=ISO-8859-15


    I have never been brave enough to try that.  Worried I would screw up the CustomRules.js (I guess.)

    Care to outline the steps required?

    I tried to use the Alt-F11 Breakpoint technique (on a 304) but apparently botched it.   Added your header but it still rendered as text.

    Let's try a Ctrl-F5...  That makes it easier to change but I'm still getting a Waiting for zebi... in my Tab label.   So I'm still missing a step.   ; ]




    Wednesday, March 13, 2013 3:32 AM
  • @Robert Aldwinckle :  I am a bit confused. In the link I provided, there are no "text/plain" Content-type. 

    I see a "Content-Type: multipart/related" on the fifth line, and then each "NextPart" section has its own Content-Type, but none is "text/plain".

    I corrected my original example here with what I said, and it doesn't help: http://shar.as/uMNbU

    I suppose I didn't get something right ...



    Wednesday, March 13, 2013 4:44 PM
  • In the link I provided, there are no "text/plain" Content-type. 

    As idle curiosity explained, it is the response header (e.g. the response to the download request) which needs to be changed and apparently Fiddler could be used to do this if you cannot make such a change on your server.   I still can't make it work with an Alt-F11 in Fiddler and a Ctrl-F5 in IE, so I still need to find a better way of trying to make IE see that the file should be treated as an E-mail and not plain text.  I suspect it will be another example of where a refresh, even a Ctrl-F5 refresh is not enough when a change of format is involved.   RSS is another example.  E.g. in order to test a change of the Feed reading view I had to do a Ctrl-k to clone the tab and not just expect a refresh of an existing tab to show a change of format, even after a Ctrl-F5 (which seems broken to me.)

    Oh.  So why don't I try that now?  Great (not).  Ctrl-k checks a cached copy.  Of course the response does not contain a Content-type header.  I tried adding a Content-type header to it anyway and ended up with a blank page in the cloned tab.   So, I'll try using the Developer Tools, Cache menu to say "Always refresh..."   Not enough?   Tried adding Clear...for this domain.   That fixed the 304 problem but now I'm back to a blank page?   WTH?

    I corrected my original example here with what I said, and it doesn't help:

    As idle curiosity explained, your original file when downloaded and saved and then opened as a local file based on file extension worked as intended.   I'm wondering if your change could account for my blank page symptom (after a 200 response header modification)?   Could you change it back please?



    Wednesday, March 13, 2013 7:20 PM
  • I know you said you already defined the message/rfc822 mime type to be applied to EML, MHT and MIME.  But as you can see above, for some reason it didn't work.  That's not what's being delivered.  When I intercepted your server's Response with Fiddler and changed the Content-Type to message/rfc822, then IE10 displayed the mht correctly.  I hope this helps you track down where the trouble is.

    There are two distinct servers, I haven't been clear on that, sorry:
    - The message/rfc822 mine type was defined on my intern server at work, on which I have a complete control, and on which the problem happens in my company.
    - The source you analyzed is stored on my personal webspace, and was only put there to show you the mht content.

    I had thought that the very source of the MHT would be enough to pinpoint was the problem is ... Since I understand now that the problem seems to be happening server-side, I realize it's kind of useless to have put the file on my personal webspace, on the server of which I have no control.

    But the thing is:  For two files on the same server, one shows up correctly rendered, and the other does not. So I HAVE to assume it is something related to the source code of the said files ...

    On My Intern server @work:
    This file gets rendered correctly -> http://shar.as/XATXG
    This one does not -> http://shar.as/OsTwQ

    Look, they are SO similar... Is it something completely random or what ? :'(

    P.S. : I haven't looked into Fiddler yet, will do, as I believe it would help with the solution..


    • Edited by Bixessss Tuesday, March 19, 2013 4:50 PM
    Tuesday, March 19, 2013 4:49 PM
  • copy the entire content to the clipboard with ^C (or to a file with whatever name you want).  snapshot.  Use the right-click menu to do this.  Tip, it tells you the total number of bytes, choose that number instead of shift-cursoring all the way down.  Be sure to checkmark Show Headers beforehand.

    Oops.  I meant to try this because I think what you did may have fixed a characterset issue incidentally using it.

    What I did was a repeat of what I had described before and it worked--sort of.   So I was assuming that the data had been restored but the Content-type was still the main problem.   But I didn't get a clean rendering, so that's why I'm guessing there is still a characterset issue to find and fix up.

    I was going to try go back and try to figure that out before reporting and then lost track of this.

    So, here again, is my procedure (and ICIM I am now on W7 with IE10 in EPM):

    1. Start Fiddler and press Alt-F11 (to break on responses).   Unfortunately, I haven't figured out how to filter on only one session yet so when other sessions happen to get interrupted I just use the Resume button.)
    2. Open the problem URL in a new tab.   E.g. middleclick on its link.
    3. The first one is a 301 redirect so just let the Run to completion work
    4. The next one has the bad Content-type header (text/plain instead of the message/rfc822) so right-click Edit header and make that replacement (leaving the charset alone which I think may also need to be changed).
    5. Click Save and Run to completion.
    6. That's it.  Click Resume to let the graphic go and turn off the break point.

    This lets the message be interpreted as an .mht file but I still think that there is something wrong from a characterset point of view because it looks very messy.   I suspect the combination of Quoted-printable plus a characterset discrepancy may be accounting for that but now instead of trying to figure that out on my own and risking forgetting about this again, I'll post my results and ideas so far.   ; )



    Tuesday, March 19, 2013 7:08 PM
  • Ok guys I tried the Fiddle software (version 2) and followed your guidelines..

    A few issues arose :  the MHT file on my intern server is opened by a popup (I know, it's not very modern...).  Fiddler captures the original link (like http://intranet/index.php?page=15183) and sees the HTTP 200 for this URL, everything is fine.  But the MHT file itself, when auto-openened in a new tab via the popup mechanism, is not captured. So I go to the tab and refresh it, and then Fiddler sees a 401 and a 304 for it, but no 200.  And these don't have the Content Type info (actually, no "entity" category - but there are Cache, Client, Cookies/Login and Transport), that we can see in idle curiosity's screenshots here above.

    ANYWAY, I tried something totally different by chance and I really, REALLY do not understand what is happening:

    I log on the server with Remote Desktop, and browse to the folder containing the MHT file.  I copy the MHT file and rename it changing 1 character.

    And it works, it gets rendered correctly..........

    I checked the security, the encoding (with Notepad++), I tried comparing them, these files seem totally identical.

    But yet, one is still not rendered, the other (copied) is.  So there is a difference between the files, but I can't get it.
    Is there any way to throughfully compare files, on all aspects?


    Wednesday, March 20, 2013 4:31 PM