[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kfm-devel
Subject:    Re: Intergrating mht file to konqueror
From:       Leo Savernik <l.savernik () aon ! at>
Date:       2004-11-06 11:46:22
Message-ID: 200411061246.28096.l.savernik () aon ! at
[Download RAW message or body]


Am Freitag, 5. November 2004 23:13 schrieb Spiros Georgaras:
[...]
> > However, the multipart message predefines the default file nonetheless
> > with Content-Type: multipart/related; boundary="<xxxxxxxxxxx>";
> > type="<mime-type>", so if <mime-type> is text/html, it's the index.
>
> All the mht files I've seen are just like that
>
> > If it's not (and if it isn't any other mime-type recognised by khtml like
> > application/xhtml+xml), it's not an html file, and it should be
> > represented as a directory listing.
>
> Haven't seen anything like that in mht files....
> If you have such a mhtml file, please send or point to it.

I think there aren't any because IE doesn't support application/xhtml+xml. But 
konqueror does, therefore it should support mhtml archives whose principal 
file is of application/xhtml+xml or text/xml.
>
> > So I don't quite understand why you test for "*a* 'text/html' document"
> > instead of "*the* document as specified by the Content-Type header".
>
> Well this is done like that because there are cases when a mht file
> contains more than one 'text/html' document. I have seen this when a
> <file>.js is contained in the file, and it is defined as that
> ('text/html'). I don't know why this happens, but it does. Then you have to
> find (and display) the real html document

So you mean there are mht files whose Content-Type header points to a js file 
as the principal file in the archive, which wrongly has the mime type 
"text/html"? Does IE really generate such broken mht files?

mfg
 Leo

[Attachment #3 (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]