[ESS] ess-17.11-tgz is not compressed

[Martin Maechler]

>>>>> Martin Maechler <maechler using stat.math.ethz.ch>
>>>>>     on Fri, 8 Dec 2017 09:57:08 +0100 writes:

>>>>> Ulrich Mueller <ulm using gentoo.org>
>>>>>     on Fri, 8 Dec 2017 09:34:52 +0100 writes:

>>>>> On Thu, 7 Dec 2017, Martin Maechler wrote:
    >>> well, I'm managing the ess.r-project.org server and I
    >>> have actually mounted the file system where
    >>> ess-17.11.tgz lives and 'ls -l' and 'file' say

    >>> ls -l ess-17.11.tgz -rw-r--r--. 1 maechler sfsstaff
    >>> 3275703 Nov 13 15:13 ess-17.11.tgz

    >>> file ess-17.11.tgz ess-17.11.tgz: gzip compressed data,
    >>> last modified: Mon Nov 13 14:13:29 2017, from Unix

    >> So ess-17.11.tgz is what we distro builders would call
    >> the "pristine tarball". It is the file that should be
    >> stored after downloading and whose integrity is verified
    >> with a checksum [1].

    >>> Now look closely at the output of wget -- which I can
    >>> reproduce in my (Fedora 26) Linux :

    >>>> ~/tmp/ess $ wget
    >>>> http://ess.r-project.org/downloads/ess/ess-17.11.tgz
    >>>> --2017-12-05 08:12:09--
    >>>> http://ess.r-project.org/downloads/ess/ess-17.11.tgz
    >>>> Resolving ess.r-project.org... 129.132.119.195
    >>>> Connecting to
    >>>> ess.r-project.org|129.132.119.195|:80... connected.
    >>>> HTTP request sent, awaiting response... 200 OK Length:
    >>>> 3275703 (3.1M) [application/x-tar]
    >>> ^^^^^^^^^^^^^^
    >>>> Saving to: ‘ess-17.11.tgz’
    >>>> 
    >>>> ess-17.11.tgz
    >>>> 100%[===========================================================================================>]
    >>>> 3.12M 6.30MB/s in 0.5s
    >>>> 
    >>>> 2017-12-05 08:12:09 (6.30 MB/s) - ‘ess-17.11.tgz’ saved
    >>>> [8898560]
    >>> ^^^^^^^^

    >> Regardless of wget's choice of defaults (which is a
    >> separate discussion), I believe that the server's
    >> response is not correct:

    >> | $ wget --server-response
    >> http://ess.r-project.org/downloads/ess/ess-17.11.tgz |
    >> --2017-12-08 09:07:29--
    >> http://ess.r-project.org/downloads/ess/ess-17.11.tgz |
    >> Resolving ess.r-project.org... 129.132.119.195 |
    >> Connecting to
    >> ess.r-project.org|129.132.119.195|:80... connected.  |
    >> HTTP request sent, awaiting response...  | HTTP/1.1 200
    >> OK | Date: Fri, 08 Dec 2017 08:07:29 GMT | Server:
    >> Apache/2.2.32 (Unix) | Last-Modified: Mon, 13 Nov 2017
    >> 14:13:29 GMT | ETag: "3e16cc-31fbb7-55ddddfe47440" |
    >> Accept-Ranges: bytes | Content-Length: 3275703 |
    >> Keep-Alive: timeout=15, max=100 | Connection: Keep-Alive
    >> | Content-Type: application/x-tar | Content-Encoding:
    >> gzip | Length: 3275703 (3.1M) [application/x-tar] |
    >> Saving to: ‘ess-17.11.tgz’ | [...]  | 2017-12-08 09:07:34
    >> (714 KB/s) - ‘ess-17.11.tgz’ saved [8898560]

    >> The server is sending a "Content-Encoding: gzip" header,
    >> indicating that gzip is used for transport compression,
    >> and that the compression should be undone on the
    >> receiver's side. But see above, we consider ess-17.11.tgz
    >> as the pristine sources, not ess-17.11.tar. So the server
    >> should neither apply nor indicate any Content-Encoding
    >> for it.

    >>> so indeed wget seems to do __silly!__ behave a bit
    >>> magically nowadays ... -- at least being honest about
    >>> it:

    >>> It gets a *.tgz of size 3275703 bytes (~ 3.1 M) and
    >>> internally uses gunzip absolutely with*OUT* saying so,
    >>> but then honestly reports that the result is of size
    >>> 8898560 bytes

    >> No. The client is explicitly asking for a .tgz file, but
    >> the server indicates in its response that it is sending a
    >> tar file (incorrectly named *.tgz, on top of that) which
    >> is compressed only for the purpose of transport.

    >> I don't want to clutter this message with another log,
    >> but in the downstream bug report [2] you can see that
    >> downloading the file from one of the Gentoo mirrors
    >> behaves correctly.


    >> [1]
    >> https://gitweb.gentoo.org/repo/gentoo.git/tree/app-emacs/ess/Manifest
    >> [2] https://bugs.gentoo.org/639752#c8

    > Thank you, Ulrich.

    > Your reasoning seems quite convincing, and I am enquiring
    > why our server does what you show above it does, and how
    > we can change that.

and it has been changed now .. with thanks to Ulrich (and our
D-MATH ETHZ Webmaster who reacted so quickly) :

Martin


$ wget --server-response http://ess.r-project.org/downloads/ess/ess-17.11.tgz
--2017-12-08 11:13:57--  http://ess.r-project.org/downloads/ess/ess-17.11.tgz
Resolving ess.r-project.org (ess.r-project.org)... 129.132.119.195
Connecting to ess.r-project.org (ess.r-project.org)|129.132.119.195|:80... connected.
HTTP request sent, awaiting response... 
  HTTP/1.1 200 OK
  Date: Fri, 08 Dec 2017 10:13:57 GMT
  Server: Apache/2.2.32 (Unix)
  Last-Modified: Mon, 13 Nov 2017 14:13:29 GMT
  ETag: "3e16cc-31fbb7-55ddddfe47440"
  Accept-Ranges: bytes
  Content-Length: 3275703
  Keep-Alive: timeout=15, max=100
  Connection: Keep-Alive
  Content-Type: application/x-gzip
Length: 3275703 (3.1M) [application/x-gzip]
Saving to: ‘ess-17.11.tgz’

ess-17.11.tgz              100%[=====================================>]   3.12M  --.-KB/s    in 0.03s   

2017-12-08 11:13:57 (99.6 MB/s) - ‘ess-17.11.tgz’ saved [3275703/3275703]

$