AW: need help for decompress URL - its a rev-win bug!

[Tiemo Hollmann TB]

Hello Jan, Eric and Robert,
@Jan: I added " application/gzip gz" to my .htaccess and got " Content-Type:
application/gzip" back in the libURLLastRHHeaders(), but the number of bytes
of my file still was changed and kept corrupted.
@Eric: I tried also a path without dots, without any change in the result.
@Robert: I tried also to first download and then uncompress, but as I wrote,
it wasn't the decompress, but already the download.

What I did then, was testing a standalone on a Mac and voila, my same stack,
same statements, same file, same path and same server - the download and
decompress works like a charme as it should do. I would have never thought
it could be a Win bug with such a super standard function, otherwise I would
have tested it much earlier on Mac to verify.
There is also a difference in the libURLLastRHHeaders()
1. The Content-Length is different on Win/Mac
2. On Mac there is an additional info line: "Content-Encoding: x-gzip" what
is not on Win.

I'll put it in the QCC and hope it gets some votes before the next release.

Thanks you all for your help!
Tiemo


> >
> 
> Hi Tiemo,
> 
> The content-type is indeed your problem, as it should
> be something along the lines of "application/gzip" -
> but this is to be configured on the server side, in
> Apache. So you should have a chat with the system
> administrator to configure the right MIME-type for the
> .gz extension.
> 
> When the content-type is "text/plain" there may be
> conversions along the way. Which is why it's also
> important in FTP to upoad/download files as binary
> when it's not a text file.
> 
> HTH,
> 
> Jan Schenkel.
>