Comment 42 for bug 589236

(In reply to comment #40)
> Wolfgang, what worries me about this setup is that if I send an application/pdf
> file with a .pl extension your browser will happily run it through a perl
> interpreter with this patch, right? And if a firewall was trying to enforce
> things based on MIME type, we lose.

if there is not default handler for application/pdf but we know one for *.pl that will be the case indeed.
I see the issue but what would be the better option? I.e. what is the desired behaviour?
Only fall back to the extension for application/octet-stream?

> Similarly, if I ask for the MIME info for a text/html file with a .cgi
> extension, and there is no default text/html handler but there _is_ a .cgi
> handler, we'll come back with a MIME info for text/html and extension .cgi.
> Not that likely, since we have default handlers for text/html, but if you have
> a CGI that produces types you do _not_ have default handlers for (e.g. word
> documents or C++ files or whatever) then this could well affect the "save as"
> codepath: see the getDefaultExtension function in contentAreaUtils.js.
> Automated testing coverage for this stuff is spotty; what sort of manual
> testing has been done here?

Hmm, I haven't seen that issue with that patch but I don't think I've tried to actually trigger such a case.
The patch should still basically do the right thing without setting the primary extension though. I'll try to verify...