On 24-Jul-05 12:01:55 Xavier Le Bris wrote: >Hello,
>A contribution to compression with gzip and some answers to Maurizio's >questions : >It is a good idea to put the whole stuff in another unit. >a/ The site 'http://www.pipeboost.com/' works today for me in T_HttpCliGz. >If not, check if zlib.dll is well loaded. This URL answer with the gzip encoding, but there is an error in your code. In xZlibDll in the ZLibLoadDll procedure if the first LoadLibrary fail then you try using different dll names. But you will not reassign the ZLibDllHandle variable. Another little change that I made in the same unit is to move the uses of Windows unit from the implementation section to the interface. I'm using Delphi 5 and it is unable to found the pByte declaration. The URL is yours? I noticed that if http version is 1.0 then in the answer of the server there is two times the header "Connection: keep-alive" (the second has the first letters capitalized). Last observation. I tried to compile your HttpGzAsy project but I get an error because the xChrono unit is missing. >b/ FGzTime is used to know the time of reception and decompression. It can >help to choose a good compression level on the server side. For example, I >chose level 6 in a first time for one of my sites. After tests, the level 1 >was better... Ok, then it is no neecessary for normal use. I have not reported it. >c/ I chose to decompress at the end of reception, because in my xGzipStream >unit, the decompression is done for the whole stream after reading the number >of uncompressed bytes. This value is at the end of the stream. We may >decompress on the fly, but the units have to be rewritten. With the actual >RAM memory, I don't think it is necessary. The whole thing is made in a way that it is a choiche of the developer of the coding class if it is handled on the fly or at the end. >d/ I think that the RcvdStream can contain the compressed data during the >reception. So, RcvdCount can be used for a progress bar. At the end of >reception, I consider, according to François's message of 09/05/2005 ("the >user has not to know if the received data were compressed or not") that >RcvdStream and RcvdCount are relative to uncompressed data. I don't see why >we have to keep the uncompressed data. Only my variable GzContentLength keeps ^^ I imagine you mean compressed data. >the compressed length. I don't think that use RcvdStream for receiving compressed data is a good idea because it will be more delicate to cleanup. Moreover it is possible that more than one encoding are applied to the body and in this case the situation will be even worse, not to mention the case of on the fly decoding. In my propose the RcvdStream will contain only the uncompressed data. And about the RcvdCount, I think that it is better if it still contain the byte effectly received. Changing it could mess up existing code. Similar question for ContentLength: should it contain what is specified in the header or the effective final length of the body? Francois? >e/ FRequestVer is set to 1.1, because some site don't compress if 1.0 is >sent. Ok, but it is not necessary to limit to the 1.1 version. In that case the server simply will not compress the data. >f/ In my code, I have a GzAcceptEncoding boolean to disconnect compression if >necessary. It would be nice to keep it in case of problem with some sites. It is still possibile to enable/disable each coding. Use HttpCli.ContentCodingHnd.CodingEnabled[<name of coding>] >Sorry, I have not time today si answer other questions. No problem :-) Bye, Maurizio. -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
