If we are not going to use compression, or we are handling it in
our own code, why link the zlib library?
You said you are not using the v7 component, so none of this currently
effects your applications. It is not realistic to make the code more
complicated just to satisfy compatibility
> If we are not going to use compression, or we are handling it in
> our own code, why link the zlib library?
You said you are not using the v7 component, so none of this currently
effects your applications. It is not realistic to make the code more
complicated just to satisfy compatibility for
There is nothing to stop you using alternative compression libraries, I
have applications using different components each with their own versions
of zlib.
Yes, of course, but why increase final application size, and resources
used, if we can simple add the possibility to not duplicate it,
> Sadly you removed the possibility to completely exclude linkage to
> ICS ZLib :(
This is consistent behaviour with other ICS v7 components, content
compression is determined by configuration defaulting as disabled, not by
compiler defines.
There is nothing to stop you using alternative compres
Just to post some enhancements to my early proposed changes.
if not Assigned(FDocStream) then
PutStringInSendBuffer('Content-Length: 0' + #13#10)
else begin
if hoContentEncoding in FServer.Options then be
Hi Angus,
With one bug fix to reset the stream to the start, your code worked fine
thanks.
Don't know if this is really a bug, or if the need to reset it
correspond to a not standard way to deal with streams by the HTTPServer
component.
In order to enhance the AnswerStream functionality
> > I'm not working with v7, but here I leave a diff file. Not
> > sufficiently tested , so let me know if you find something not
> > working properly.
>
> Many thanks for the code, I'll test it on Monday.
With one bug fix to reset the stream to the start, your code worked fine
thanks.
Howe
> I'm not working with v7, but here I leave a diff file. Not
> sufficiently tested , so let me know if you find something not
> working properly.
Many thanks for the code, I'll test it on Monday.
Angus
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://list
ICS has OverbyteIcsZlibHigh with versions of many of the Zlib functions,
although only ZlibCompressStreamEx, not ZcompressStream2, but they are
probably similar.
Do you have the time to update the V7 server component (from the nightly
SVN zip) to use the existing ICS Zlib units? They are us
> From: RTT
> Some time ago I made some tests using next icshttpserver changes to
> provide gzip compression.
> Because I use the free ZLibEx unit in my projects
> ZcompressStream2(FDocStream, FZDocStream, zcDefault, 31, 9,
ICS has OverbyteIcsZlibHigh with versions of many of the Zlib function
Some time ago I made some tests using next icshttpserver changes to
provide gzip compression.
Because I use the free ZLibEx unit in my projects
uses
...
{$IFDEF USE_ZLIB}
//dZLib, zDeflate, ZLibh,
ZLibEx,
{$ENDIF}
Commented all the other code inside {$IFDEF USE_ZLIB} {$ENDIF} blocks
and
Angus Robertson - Magenta Systems Ltd wrote:
> Does anyone know who added the unfinished ZLIB code to provide
> deflated replies in the web server component?
I don't know.
> Are they going to
> finish it, or do we need to start again?
I don't think this work will be continued by anybody else bu
Does anyone know who added the unfinished ZLIB code to provide deflated
replies in the web server component? Are they going to finish it, or do
we need to start again? The current code uses units that are not part of
the distribution or Delphi.
I have many HTML pages that are very large and ben
13 matches
Mail list logo
