On 18 Aug 2012, at 00:25, Sven Van Caekenberghe <sven@beta9.be> 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