7

I am having an issue getting an iframe to display MHT files:

if( strtolower( substr( $filename , -4 ) ) == ".mht" ){

    $filename = str_replace( "/" , "\\" , $filename );

    header("Content-type: $filetype");
    header("Content-Length: $filesize");
    header('Content-Disposition: attachment; filename="'.$title.'.mht"');

    readfile( HT_STORAGE . $filename );
}
else{
    $filename = str_replace( "\\" , "/" , $filename );
    header( "location: https://secure.***************.com/" . $filename );
}

The above method works, but it requires two steps (download and open) that my clients aren't happy about.

As you can see, right now I am simply forcing the browser to open the MHT as a download. I want it to redirect using a header location so that it displays the MHT within this iframe like it does for files who don't have the MHT extension. I am assuming that this is simply a header call that tells the browser that its MHT content. With a regular redirect, the browser just shows a bunch of MHT tags, no actual content (which is why I am assuming that a special header is required). Any ideas?

EDIT:

Here is some more information I found regarding this issue. The MHT file contains several segments that look like this:

From: "Saved by Windows Internet Explorer 9"
Subject: Print Preview
Date: Tue, 2 Aug 2011 12:06:51 -0500
MIME-Version: 1.0
Content-Type: multipart/related;
type="text/html";
boundary="----=_NextPart_000_0186_01CC510C.A9789090"
X-MimeOLE: Produced By Microsoft MimeOLE V6.1.7600.16807

This is a multi-part message in MIME format.

AND

------=_NextPart_000_0186_01CC510C.A9789090
Content-Type: application/octet-stream
Content-Transfer-Encoding: quoted-printable
Content-Location: https://*******.net/packages/js/jquery.header.js

For some reason, if I use the attachment methodology and "open" the file, IE/Firefox has no problem rendering the document. If I use the header "location" method, it just displays the contents of the file (html tags, mime stuff, etc...), the the interpreted content. Doings this displays the raw HTML output, rather than actually displaying the MHT page:

if( strtolower( substr( $filename , -4 ) ) == ".mht" ){

    $filename = str_replace( "\\" , "/" , $filename );

header("Content-type: message/rfc822");
header( "location: " . $filename );
//header("Content-Length: $filesize");
//header('Content-Disposition: attachment; filename="'.$title.'.mht"');

//readfile( HT_STORAGE . $filename );
}
else{
$filename = str_replace( "\\" , "/" , $filename );
header( "location: https://secure.*****************.com/" . $filename );
}

By using content-type and location, the output is as follows on IE and FF (and most likely all other browsers):

From: "Saved by Windows Internet Explorer 9"
Subject: Print Preview
Date: Tue, 2 Aug 2011 12:06:51 -0500
MIME-Version: 1.0
Content-Type: multipart/related;
    type="text/html";
    boundary="----=_NextPart_000_0186_01CC510C.A9789090"
X-MimeOLE: Produced By Microsoft MimeOLE V6.1.7600.16807

This is a multi-part message in MIME format.

------=_NextPart_000_0186_01CC510C.A9789090
Content-Type: text/html;
    charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Location: https://kinnser.net/am/printwrapper.cfm?PatientTaskKey=36184728

=EF=BB=BF<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" =
"http://www.w3c.org/TR/1999/REC-html401-19991224/loose.dtd">
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" =
"http://www.w3.org/TR/html4/loose.dtd"><HTML><HEAD><TITLE>Print=20
Preview</TITLE>...

So rather than actually rendering the MHT, it just spits out all the tags and data.

Any ideas? Should I have to strip the "MIME" data off the files?:

------=_NextPart_000_0186_01CC510C.A9789090
    Content-Type: text/html;
        charset="utf-8"
    Content-Transfer-Encoding: quoted-printable
    Content-Location: https://kinnser.net/am/printwrapper.cfm?PatientTaskKey=36184728

If so, then how?

Edit

Ironically, if I set it up as content-disposition: attachment and use the readFile, I can open the document and it displays properly. Only if I try to directly inject it inline into the iframe does it render source code and no content. Any ideas?

Andrew Rhyne
  • 5,060
  • 4
  • 28
  • 41

1 Answers1

4

There is currently a known issue with Google-Chrome when viewing MHTs - it will always treat them as Content-Disposition: attachment and download them.

IE should always view MHTs fine.

Firefox will view them fine, if you install a plugin for it.

If the browser was actually able to display MHTs correctly, then the following headers should be sufficient:

Content-Type: message/rfc822
Content-Disposition: inline

I was running into issues with Chrome viewing MHT files as well, and in the end the solution I used was to convert the MHT to a single HTML page on the fly. This worked for the situation I was dealing with, but may not work for generic MHT files.

a_m0d
  • 12,034
  • 15
  • 57
  • 79
  • This does the same thing with IE and firefox – Andrew Rhyne Nov 14 '12 at 18:10
  • Could that MIME portion that I listed out be causing problems? – Andrew Rhyne Nov 14 '12 at 18:11
  • @AndrewRhyne The reason it is downloading is definitely because you have the `Content-Disposition: attachment` header - remove that, and it should start to work in IE at least. – a_m0d Nov 14 '12 at 18:13
  • If you read later down in the post, I specified that I used header("Content-type: message/rfc822"); header( "location: " . $filename ); – Andrew Rhyne Nov 14 '12 at 18:14
  • That first segment was the "open and view" segment that I am trying to replace with an inline view of the MHT (single step rather than two steps) – Andrew Rhyne Nov 14 '12 at 18:15
  • The `Location` header really shouldn't make any difference. What happens if you use the `Content-Type` and `Content-Disposition` headers like I mentioned above? – a_m0d Nov 14 '12 at 18:21
  • As per the updated question, Content-Disposition "downloads" it. Using the Location header does the exact same thing with and without the Content-Type header. It's all in the question if you want to review it. I added more thorough information about the problem. I really appreciate the help! – Andrew Rhyne Nov 14 '12 at 18:25
  • @AndrewRhyne I don't see anywhere in your question that you tried it with `Content-Type: inline` as opposed to `Content-Type: attachment`. If you have tried this already, please mention it in the question. Setting `inline` will tell the browser not to download it, but the only places you have this header in the question, you use the `attachment` disposition instead, which will force the browser to download the mht. – a_m0d Nov 15 '12 at 00:27
  • You're right. I used Content-Disposition: attachment. Will content-type: attachment allow the browser to open the MHT inline, rather than having to download it? That is what I need – Andrew Rhyne Nov 15 '12 at 02:18
  • Sorry, in my previous comment I meant `Content-Disposition: inline` rather than `Content-Type`. You have the correct `Content-Type`, but you just have to adjust your `Content-Disposition` to make the browser preview it inline. – a_m0d Nov 15 '12 at 18:54
  • $filename = str_replace( "\\" , "/" , $filename ); header("Content-Disposition: inline"); header("Content-type: message/rfc822"); header( "location: " . $filename ); – Andrew Rhyne Nov 15 '12 at 18:59
  • ^That just spits out the actual MHT string.... It doens't show it. But if I do this: header("Content-Length: $filesize"); header('Content-Disposition: attachment; filename="'.$title.'.mht"'); readfile( HT_STORAGE . $filename ); it downloads it and you can open it in the same browser after it downloads (by clicking open on the download dialog). I need it to render the MHT inside of page, rather than taking an extra step to view it – Andrew Rhyne Nov 15 '12 at 19:03
  • Very strange. Would you be able to provide an online example that I can view to help you? – a_m0d Nov 16 '12 at 14:48
  • Unfortunately I cannot due to the sensitivity of some of the information contained within. – Andrew Rhyne Nov 16 '12 at 16:58