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

Reply via email to