Intergrating mht file to konqueror

Spiros Georgaras sngeorgaras at otenet.gr
Sun Nov 7 09:22:26 GMT 2004


Leo Savernik wrote:
> 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.
>
Well this makes things more complicated than it was....
Because konqueror has to know in advance what to display with a given 
protocol. What I mean is that if the protocol is war (or mht up until now) 
konqueror would display a html doc (index.html).
But if for mhtml we have, according to the type:
'text/html' --> index.html
'application/xml' --> index.xml
'application/xhtml+xml' --> index.xml
unrecognized --> / with serviceType 'inode/directory'

How can we make konqueror distinguish the difference?

> [...]
> > 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?
>

No it was not IE that generate such broken mht files. It was my app kmhtCovert 
that did it :) but thanks to you I have fixed it and released a new 
tarball....




More information about the kfm-devel mailing list