Comment 138 for bug 25830

Gleep! I'm not sure I like the sound of having a dozen ad-hoc rules for when to
decode or not and what to do with file extensions--especially because as far as
http is concerned, the Content-Type and Content-Encoding headers are everything
and filename extensions are invisible to the standard.

I would suggest two very simple rules to apply in perfect uniformity, regardless
of the type of data.

1. If it's to be processed/displayed internally, then of course undo the encoding.

2. If it's to be saved to a file, and has a non-null Content-Encoding that
Mozilla knows how to undo, give the user radiobuttons on the save dialog:

  This file was sent with the encoding: gzip
  O save in this encoding
  O undo encoding and save

Then you can add file extension *heuristics* if you want, say for example if the
encoding is gzip and the suggested name in the Save dialog ends in .gz then
change the suggested name to without the .gz ... that makes these convenience
suggestions that the user sees in the dialog and has the choice to accept, not a
plethora of rules that get applied for various content types and make the user
try to figure out what happened.

As for what to do when invoking a helper: the real answer is probably allow each
helper definition to include an Accept-Encoding list. If a file comes in an
encoding the helper accepts, Moz passes the file unchanged. If the helper does
not accept the encoding but Moz knows how to decode it, then Moz decodes.
Otherwise, need to ask the user what to do.

An alternative to accept-encoding list per helper is for helpers to be a
relation indexed by (content-type, encoding). That way you could support a
helper that can accept a certain encoding but needs maybe different command line
options to do it, because the entry for that (type,encoding) pair would be able
to have its own command line. But I'm not sure all of these considerations need
to be handled for THIS bug....