* "musl" gzip-compressed tarballs are decompressed if using newest wegt release
@ 2017-11-01 10:19 Jens Schleusener
2017-11-01 15:26 ` Rich Felker
0 siblings, 1 reply; 5+ messages in thread
From: Jens Schleusener @ 2017-11-01 10:19 UTC (permalink / raw)
To: musl
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
Regards
Jens
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: "musl" gzip-compressed tarballs are decompressed if using newest wegt release
2017-11-01 10:19 "musl" gzip-compressed tarballs are decompressed if using newest wegt release Jens Schleusener
@ 2017-11-01 15:26 ` Rich Felker
2017-11-01 15:50 ` Jens Schleusener
0 siblings, 1 reply; 5+ messages in thread
From: Rich Felker @ 2017-11-01 15:26 UTC (permalink / raw)
To: musl
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.
Rich
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: "musl" gzip-compressed tarballs are decompressed if using newest wegt release
2017-11-01 15:26 ` Rich Felker
@ 2017-11-01 15:50 ` Jens Schleusener
2017-11-01 18:08 ` Rich Felker
0 siblings, 1 reply; 5+ messages in thread
From: Jens Schleusener @ 2017-11-01 15:50 UTC (permalink / raw)
To: musl
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: "musl" gzip-compressed tarballs are decompressed if using newest wegt release
2017-11-01 15:50 ` Jens Schleusener
@ 2017-11-01 18:08 ` Rich Felker
2017-11-01 19:09 ` Matias Fonzo
0 siblings, 1 reply; 5+ messages in thread
From: Rich Felker @ 2017-11-01 18:08 UTC (permalink / raw)
To: musl
On Wed, Nov 01, 2017 at 04:50:01PM +0100, Jens Schleusener wrote:
> 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.
It should be fixed now. I've written a patch for thttpd that removes
the content-transfer-encoding nonsense and submitted it for inclusion
in Alpine Linux (used on musl's web host) and already installed the
patched package myself. Hopefully this will eventually make it
upstream to thttpd, but it seems mostly unmaintained.
FWIW I'd love to switch to a better httpd that's actually maintained,
but I need something with simple migration path and without loads of
unwanted bloat. Needs to be able to:
- support host header based vhosts, translated to dir names under web
root.
- execute cgi (only!) from a configured whitelist of pathnames
- support url paths that go past the cgi program, i.e. /cgit/musl/...
where /cgit is the cgi executable
- honor symlinks (without any attempt to [re]interpret them)
Solution which involve a process per static-content request are not
really desirable. Recommendations would be welcome.
Rich
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: "musl" gzip-compressed tarballs are decompressed if using newest wegt release
2017-11-01 18:08 ` Rich Felker
@ 2017-11-01 19:09 ` Matias Fonzo
0 siblings, 0 replies; 5+ messages in thread
From: Matias Fonzo @ 2017-11-01 19:09 UTC (permalink / raw)
To: musl
On Wed, 1 Nov 2017 14:08:07 -0400
Rich Felker <dalias@libc.org> wrote:
> On Wed, Nov 01, 2017 at 04:50:01PM +0100, Jens Schleusener wrote:
> > On Wed, 1 Nov 2017, Rich Felker wrote:
>
> [..]
>
> FWIW I'd love to switch to a better httpd that's actually maintained,
> but I need something with simple migration path and without loads of
> unwanted bloat. Needs to be able to:
>
> - support host header based vhosts, translated to dir names under web
> root.
>
> - execute cgi (only!) from a configured whitelist of pathnames
>
> - support url paths that go past the cgi program, i.e. /cgit/musl/...
> where /cgit is the cgi executable
>
> - honor symlinks (without any attempt to [re]interpret them)
>
> Solution which involve a process per static-content request are not
> really desirable. Recommendations would be welcome.
>
Take a look to http://www.hiawatha-webserver.org/
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2017-11-01 19:09 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-11-01 10:19 "musl" gzip-compressed tarballs are decompressed if using newest wegt release Jens Schleusener
2017-11-01 15:26 ` Rich Felker
2017-11-01 15:50 ` Jens Schleusener
2017-11-01 18:08 ` Rich Felker
2017-11-01 19:09 ` Matias Fonzo
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).