An annoyance I've had for some time when downloading SBo packages and SlackBuilds is that the package.tar.gz file gets unzipped when it's downloaded (not the source file, just the package file).

I've fiddled with Firefox Preferences and Tar archive is to to Save File and Gzip archive is set to Save File and I'm wondering what the heck is going on.

It's not a big deal, I know that the package file is unzipped (for example, yasm.tar.gz) and I just use [I]tar xvf/I]) where the source file (say, yasm-1.1.0.tar.gz) does not get unzipped.

Is there some setting somewhere that I've missed?

Hi, former colleague @ AMC

I came across the same issue, I think (or reverse?).

HTH,

[duplicate post]

Well, hi yourself (and thanks for the link)

I've more or less decided (after reading the link) to leave the thing alone and just deal with it.

The odd thing is that this seems to be size related (maybe, maybe not) -- the SlackBuild file is small (by comparison to anything else, particularly the source code) and, maybe, there's something or other somewhere or other that just says, "OK, it's small, gunzip it." It's a feature. But it really isn't gunzipped because the file name doesn't lose the ".gz."

Oh, well.

Thanks for the input.

1. Are you sure its not an addon?

2. Have you checked preference > application? Is there an entry related to the type of files firefox is unzipping? If yes then there must be a drop down menu for further options to disable it. I am talking from firefox 33

I use wget in a designated directory. Just copy paste the URL into wget with the -c flag and it works just as good as any browser.

Yes it could be a add-on or it could be caused by setting a default flag to the browser downloader.

Pretty sure: only add-ons are Adblock Plus, EPUBReader and NoScript.
OK, so why does filenmae.tar.gz (the SlackBuild) get unzipped and sourcename.tar.gz not get unzipped? And the preferences are set to "save file" and "ask me about gzip."

Don't make no sense to me.

I'm not aware that SlackBuilds.org has an ftp (which would also be wget) option?

Gotta look into that, thanks.

There's a default setting in about:config

If changed from (gzip, deflate) into () does it still happen?

I use this ( the empty setting ) and now sites that I previously had downloaded doubly gzip'd files from, now download normal tarballs. No adverse effects to other aspects of browsing have I noticed. This issue with gunzip'ing tarballs I have never seen before, on SlackBuilds.org or any other site... only tarballs getting gzip'd a second time. I think the second gzip of the file was by the server; usually sourceforge was the biggest problem for me with this. I apologize if this is unrelated.

2 members found this post helpful.

The network.http.accept-encoding shouldn't affect the download of files. Its purpose is to tell the web server what encoding your browser will accept for content files (html, js, css, etc...) transferred to the browser. While slackbuilds.org doesn't use this, go to Google and you can see the individual files being transferred in a compressed manner (you can look in the response header). I said "shouldn't" because you indicate that there is a behavior difference.

@tronayne, I got curious and looked at yasm on slackbuilds.org. I can see why you are seeing a difference. I cannot explain the difference, but I can point out what I believe the trigger is to you.

The yasm.tar.gz has the following in its response headers when I go to download it:

Content-Encoding:"gzip"
Content-Type:"application/x-gzip"

The yasm-1.1.0.tar.gz has the following in its response headers (keep in mind this is coming from a different site):

Content-Type:"application/octet-stream"

There is no Content-Encoding header in the response from that site. The site is also an Nginx server as opposed to Apache on slackbuilds.org. although I don't believe that matters as much as the Content-Type being returned. So maybe I am wrong about the affect that the accept-encoding config item is having, but I get the same result either way when downloading the file from my Firefox (currently 33.1).

Regardless, the Content-Type is more than likely the trigger that is causing the different behavior for you.

An that's wrong. So I think the server is misconfigured.

It could either serve the .tar archive via Because .tar doesn't have an officially registered MIME type. Or better just the .tar.gz using which is the correct MIME type for .gz files.

IMHO for file transfers Content-Encoding shouldn't be used at all.

So what I'm getting is that the SlackBuilds.org Apache server is not configured correctly? Hmm.

OK, I'll write off to them and see what may be what -- the odd thing is that only the SlackBuild file is unzipped (but apparently not with gunzip because the file name does not lose the ".gz" at the end, it's simply a tar file with a ".gz".

Thanks for the input and I'll get back with whatever I may find out.

It's a combination: the server sending content-encoding, and something is weird in your firefox. The content-encoding sent by Slackbuilds.org is not wrong - I think it is in the default Apache config - and it doesn't affect most of us. But other servers don't send it. I think sourceforge download mirrors don't send it. Unfortunately, I don't know what is different in your Firefox that is doing this. (I assume it is firefox, but it could also be something like a proxy server or even an anti-virus thing that is doing the decompress.)

It is wrong, because it says that content was encoded by the web server and should be decoded by the browser. Which is exactly what Firefox does. Firefox then saves a tar.gz file, because the web server told the browser, the decoded content itself is of MIME type application/x-gzip, which is wrong either.