2030897 - Add MHTML (RFC 2557) read support for .mhtml / .mht files

Status: ASSIGNED

(Core :: DOM: Serializers, enhancement)

Description

[Jonathan Kingston [:jkt] he/him]

Implement native loading and rendering of MHTML archives (RFC 2557, multipart/related) so Firefox can open .mhtml and .mht files produced by Chromium and other tools. This is the read half of bug 40873, split out so it can land independently of export.

Comment 1

[Jonathan Kingston [:jkt] he/him]

Attachment: WIP: Bug 2030897: Add MHTML export support, PoC patch.

Comment 2

[Duncan McIntosh [:dmcintosh]]

Attachment: WIP: Bug 2030897 - Pre: Add nsIContentSubstitution to replace channel opens for a given document.

Comment 3

[Duncan McIntosh [:dmcintosh]]

Attachment: WIP: Bug 2030897 - Add the MHTML parser and tests; will be split prior to review, don't want to spam Bugzilla.

Comment 4

[Duncan McIntosh [:dmcintosh]]

Attaching my changes here too to avoid cluttering bug 18764, still lots of work to do.

:jkt, looks like you might've gotten the patches and bugs mixed up? The bug description says this is read/import, but your patch is export...? (Also can move mine if you'd rather swap the bug meanings.)

Comment 5

[ajf]

Hey, I apologise for possibly retreading covered ground here, but: what origin behaviour will this have? This might be a somewhat radical suggestion, but for my part, I would really like it if MHTML files get treated as their own origin, differently from an HTML file accessed via file://. The reason is that there's currently a lot of web functionality that you can't use from a downloaded HTML file due to security concerns, and this forces you to host something on a local webserver if you want to use those features. I also understand there's various security concerns with how normal HTML files accessed via file:// behave. If MHTML files could be treated differently, they would become very valuable as a format for delivering small applications. It would probably also mean that less things break when you do a “Save Page As”.

Comment 6

[Marc]

Then you can just enable everything with file:\ as you would just have to rename your .html to .mhtml to circumvent the security of file:\
There should be a better solution like asking the user if he allows access to .... if loaded from disk.

Comment 7

[ajf]

Maybe I'm missing something, but as I understand it, the security problem with file:// URLs is that they can access arbitrary files on your local filesystem. That's kind of inherent to the model for HTML files, but since MHTML files can embed any resources they need, couldn't they be forbidden from accessing anything via file://, and therefore be free of that security concern? In which case it would no longer be unreasonable to allow them to, say, make HTTP requests.

Comment 8

[Duncan McIntosh [:dmcintosh]]

(In reply to ajf from comment #5)

If MHTML files could be treated differently, they would become very valuable as a format for delivering small applications. It would probably also mean that less things break when you do a “Save Page As”.

I agree that it'd be wicked cool, the problem is that scripts are full of edge-cases and things that can go wrong and cause security issues. Also, one neat thing about MHTML is that the content is constant over time, but with scripts the content could depend on e.g. the current date/time.

My current plan (and I think jkt's too) is to follow Chromium's lead in not allowing script in MHTML, maybe with a lot of care that could be relaxed later. It's kind of a balance between 'this is a web archiving format' and 'this is a web app distribution format (like EXE but in-browser)', both are cool but the tradeoffs differ.

(In reply to ajf from comment #7)

In which case it would no longer be unreasonable to allow them to, say, make HTTP requests.

On the one hand this would be kind of cool, but even notwithstanding possible remaining security concerns this could e.g. allow an MHTML file to 'phone home' whenever you look at it, or to implement DRM, which is another 'should they be able to do that' thing. (Also, if you could make HTTP requests, couldn't you put the app on that server and avoid the need for MHTML? True that wouldn't keep the same version over time, but the server could change and break your older version anyways.)

Comment 9

[Duncan McIntosh [:dmcintosh]]

:jkt, I'm curious what your current status is on this? I'm hoping to have loading patches up soonish, but I don't have anything for saving at this point. If you don't have time I'm happy to try it, but if you're still planning to do it then I'll avoid working on that for now.

Comment 10

[Duncan McIntosh [:dmcintosh]]

Attachment: WIP: Bug 2030897 - Patch 2: Add an nsIStreamConverter instance to use when loading substituted content.

Comment 11

[Duncan McIntosh [:dmcintosh]]

Attachment: WIP: Bug 2030897 - Patch 3: Map .mht, .mhtml to application/x-mimearchive.

This is used in the tests for nsIContentSubstitution.

Comment 12

[Duncan McIntosh [:dmcintosh]]

Attachment: WIP: Bug 2030897 - Patch 4: Add tests for content substitutions.

Comment 13

[Duncan McIntosh [:dmcintosh]]

Attachment: WIP: Bug 2030897 - Part 0: Add documentation explaining how Content Substitution works.