[Slackbuilds-users] Fwd: [uzbl-dev] Problem downloading gzipped tar files

[Donald Allen]

Robby --

Below is a response from one of the uzbl developers to a message I
sent them, which unfortunately is truncated in his response. The issue
is that with the uzbl browser, which is built on top of webkitgtk,
when I download slackbuild tar files, they get gunzipped, though the
locally stored file is still named foo.tar.gz. As mentioned below, I
do not see this behavior when downloading .tar.gz files from other
sites, nor do I see it with Firefox. His message explains all this,
including asserting that slackbuilds.org sending "Content-Encoding:
gzip" is incorrect. If you agree that this is an error (in my
experience, the uzbl guys know what they are talking about when it
comes to browser matters, web protocols, etc.), please put fixing this
on your to-do list.

By the way, my earlier message about the flash-plugin slackbuild may
have been a result of this problem. I don't remember if I tried
downloading it with firefox. If I didn't, the file may actually have
been ok and was delivered uncompressed to me because of the above
issue.

Thanks --
/Don


---------- Forwarded message ----------
From: Dan Winship <danw at gnome.org>
Date: Thu, Apr 7, 2011 at 8:17 AM
Subject: Re: [uzbl-dev] Problem downloading gzipped tar files
To: Donald Allen <donaldcallen at gmail.com>
Cc: uzbl-dev at lists.uzbl.org


On 04/06/2011 11:24 PM, Donald Allen wrote:
> uzbl, what I end up with is the tar file gunzip-ed, but it is still
> named foo.tar.gz. For example, go to
>
> http://slackbuilds.org/repository/13.1/academic/ess/
>
> and click the 'ess.tar.gz' link. Unless there's something about my
> setup that's causing this, you will get an ess.tar.gz file that is
> actually an uncompressed tar file. Doing the same with Firefox 3.6.15
> results in a
> gzipped tar file, as one would expect.

> I do not see this behavior when downloading gzipped tar files from
> some other sites, e.g., gnucash.org.

It's because slackbuilds is sending "Content-Encoding: gzip", which is
wrong. Other browsers work around this, but WebKitGTK doesn't.

There's a bug at https://bugzilla.gnome.org/show_bug.cgi?id=613361. We
never got around to figuring out exactly how Firefox is special-casing
this, so it never got fixed.

-- Dan