[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug-wget] New wget (1.19.2): Unexpected download behaviour for gzip-com

From: Jens Schleusener
Subject: [Bug-wget] New wget (1.19.2): Unexpected download behaviour for gzip-compressed tarballs (HTTP-header dependent)
Date: Wed, 1 Nov 2017 17:27:58 +0100 (CET)
User-agent: Alpine 2.20 (LSU 67 2015-01-07)


the new "wget" release 1.19.2 has got a new feature:

 "gzip Content-Encoding decompression"

But that feature - at least for my self-conmpiled binary - leads to a problem if one downloads gzip-compressed tarballs from sites that send for e.g. an HTTP response header containing lines like

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

In that cases wget saves a downloaded gzip-compressed tarball now decompressed (!) what probably breaks a lot of scripts. Additionally the tarball is saved nevertheless under a filename with the "tar.gz" extension and not with the "tar" extension.

Solutions/workarounds may be on affected servers the delivering of an alternative 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


But maybe it would be better if for such cases wget would revert its default behaviour to the old one. Or is the described behaviour the expected one?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]