> a) use the new httpcli to verify if it still "works" as before, i.e. 
> doesn't break your code (no gzip nor dll involved)

The 5 June version does seem to be backward compatible, without 
{$DEFINE Xlb_GzHttp}. 

> b) test it with your gzip implementation if you made it in a inherited 
> component, again to check if it still works

Sorry, as soon as I define Gzip, it all falls over, this is using the 
various x*.pas files with the DLL.  

I'm testing my high level HTTP component and demo program (available 
from the SSL download page), against my local IIS/5 server with the 
(free) FlatCompression ISAPI filter installed to go gzip.  

When my component does a HEAD request an Accept-Encoding: gzip header 
is added and there is no response from the server, don't know whose 
error this is, but it goes away when I force HTTP 1.0 to stop the gzip 

When I do a GET, the stream returned is still compressed.  Initially I 
was testing with the DLL in the ICS source directory, which is 
obviously silly but also the reason I said I'd never deploy this using 
a DLL, but it's no better with the DLL in the program directory, and 
there are no exceptions either warning the DLL is missing.   

> c) try to implement a gzip extention that use your favorite library 

Not until the base compoment works.  I don't see any logical means to 
add 'extensions', I assume you mean simply replacing your 
xgzipstream.pas' code? 

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