On 18 Aug 2012, at 00:25, Sven Van Caekenberghe <[email protected]> wrote:
> Hmm, interesting !
>
> I have to study this further and read the specs.
After a lot of reading and experimenting, these are my conclusions. If anyone
can contribute to this issue, please do.
Doing the following works correctly as far as I understand it
ZnClient new
url: 'http://www.iana.org/time-zones/repository/tzdata-latest.tar.gz';
downloadTo: FileDirectory default pathName;
yourself.
ZnClient new
get: 'http://www.iana.org/time-zones/repository/tzdata-latest.tar.gz';
yourself.
The second expression is more interesting because it allows you to inspect the
complete response object not using a streaming download.
This reveals that the content-type is application/x-tar which is weird because
the client requests a file whose primary type is x-gzip. It also reveals that
the content-encoding is gzip, which Zn correctly handles by uncompressing the
transferred bytes. From this last fact, a content-type of application/x-tar is
then again understandable.
Given the fact that the server is Apache/2.2.3 (CentOS) this has to be the
result of some explicit configuration.
My standard apache works differently
ZnClient new
get: 'http://stfx.eu/test.tar.gz';
yourself.
Here, no content-encoding is done and the requested file is served as
application/x-gzip, hence Zn will not do any uncompression.
What confuses me is that both curl and browsers including safari and firefox
seem to things differently: they do not do any uncompression on the first URL
which results in the compressed file being downloaded and saved, effectively
ignoring the gzip content-encoding. This must be a feature, but I can't find
any references describing it.
In my understanding of the specs, the following would be a way to request not
to use gzip content-encoding, but it does not work as expected
ZnClient new
url: 'http://www.iana.org/time-zones/repository/tzdata-latest.tar.gz';
headerAt: 'Accept-Encoding' put: 'identity';
downloadTo: FileDirectory default pathName;
yourself.
Sven
