Invalid tar magic when streaming download

[Eli Schwartz]

On 12/5/19 8:03 PM, Jeffrey Fetterman wrote:
> Hey, I'm not the one who decided that both zipballs and tarballs on
> GitHub should use DEFLATE compression on random files.
I'm genuinely not sure if you're trolling. The url you used is an HTTP
302 redirect to

Location: https://codeload.github.com/mirror/busybox/legacy.tar.gz/master

Which in turn specifies:

Content-Type: application/x-gzip
Content-Disposition: attachment;
filename=mirror-busybox-1_31_0-98-g9ec836c.tar.gz

But most people don't bother using the legacy API, and instead use the
publicly linked urls like
https://github.com/mirror/busybox/archive/master.tar.gz

Which is a 302 redirect to:

Location: https://codeload.github.com/mirror/busybox/tar.gz/master

Which in turn declares:

Content-Type: application/x-gzip
Content-Disposition: attachment; filename=busybox-master.tar.gz

So, I'm bewildered why you would be surprised that a compressed tarball
would be "randomly compressed", and I'm not sure why you are blaming
github for ruining your experiment or whatever. You want to experiment
with how tar decompresses files from a pipe? I suggest you use

gzip <infile.tar | busybox tar -xf -

This produce controllable experiments where you know and can account for
your inputs.

P.S. I'm unaware of anyone hosting software forges, git-based or
otherwise, who offer non-compressed tarballs for download. It would be
stupid of them to offer it, because why on earth would you go ahead and
shoot your own bandwidth in the foot like that?

How did you get into the developer API documentation of github without
realizing this fact?

-- 
Eli Schwartz
Bug Wrangler and Trusted User

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1601 bytes
Desc: OpenPGP digital signature
URL: <http://lists.busybox.net/pipermail/busybox/attachments/20191205/4dbbfebd/attachment.asc>