|
Message-ID: <alpine.LSU.2.20.1711011645200.5399@schiller.site> Date: Wed, 1 Nov 2017 16:50:01 +0100 (CET) From: "Jens Schleusener" <Jens.Schleusener@...nline.de> To: musl@...ts.openwall.com Subject: Re: "musl" gzip-compressed tarballs are decompressed if using newest wegt release On Wed, 1 Nov 2017, Rich Felker wrote: > On Wed, Nov 01, 2017 at 11:19:30AM +0100, Jens Schleusener wrote: >> Hi, >> >> not a real "musl" software problem but just an observation of a >> changed behaviour of "musl" tarball downloads with the newest "wegt" >> release (1.19.2): The tarballs are saved now decompressed but >> contains the original extension (.tar.gz). Although if the extension >> would be .tar it seems at least to me an undesired behaviour. >> >> Reason seems a new "wget" feature, here some extracted lines taken >> from the ChangeLog >> >> 2017-08-04 >> Add gzip Content-Encoding decompression >> (gethttp): Decompress files with gzip Content-Encoding >> >> in combination with the HTTP header the www.musl-libc.org server delivers: >> >> Content-Type: application/x-tar >> Content-Encoding: gzip >> >> Solutions/workarounds may be on the server side delivering of a HTTP >> header like >> >> Content-Type: application/x-gzip >> (or Content-Type: application/octet-stream) >> >> or on the client side the use of the new "wget" option >> >> --compression=none > > IMO this is both a bug in the server and a major regression in wget, > since lots of servers have this bug. I'll look at fixing it on my side > but I think it should be reported to wget and reverted since this is > going to break a *huge* number of build scripts that download tarballs > from affected servers. Thanks for the more clear statement (I agree). If not already done by another person I will send an accoding mail to the "bug-wget" list. Jens
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.