It just seems like feature-creep and YetAnotherDirective for something that is better handled some other way. As OtherBill notes, a small edit to the magic file "fixes" this.
> On Jan 8, 2016, at 11:16 AM, Yann Ylavic <ylavic....@gmail.com> wrote: > > On Fri, Jan 8, 2016 at 1:43 PM, Jim Jagielski <j...@jagunet.com> wrote: >> -0.9... >> >> This seems a very heavy solution to a specific one-off problem. > > Not sure this is the patch which is heavy here... > Anytime mod_mime_magic recognizes the type of a gzip file (by the > magic bytes), it unconditionally starts a new piped-process to > uncompress the file so to determine the type of the gzipped content. > Then, it forces "Content-Encoding: x-gzip" and (eg.) "Content-Type: > x-tar", which causes the browser to think this was an original tarball > compressed by the protocol, and then uncompress it for the user to get > the (supposedly) original file. > (Btw the "Content-Encoding" encoding is set whether or not the > underlying type has been determined successfully, that looks buggy to > me since the browser could get a C-E w/o C-T, so I fixed it in the > proposed patch too). > > My patch simply disables this by default (and provides an opt-out to > restore legacy behaviour, but it could easily take the other way too > to preserve existing), such that now mod_mime_magic can also set only > "Content-Type: x-gzip" and let (real) original go out with no special > treatment. > > The patch is actually quite small to handle this IMHO...
