W3C home > Mailing lists > Public > www-lib@w3.org > January to March 2001

Re: Adding zlib to libwww applications

From: Jeff Adams <jeffa@coursewave.com>
Date: Mon, 19 Feb 2001 09:23:41 -0600
Message-ID: <3A913A7D.4AC0EACB@coursewave.com>
To: www-lib@w3.org
> Adding zlib to libwww applications
> Message-ID: <F3327358F65CD31196DE00A0C9FC4F79011975EA@MAIL>
> From: Ailleen Lien <alien@clientsoft.com>
> To: www-lib@w3.org
> Date: Thu, 1 Feb 2001 14:30:43 -0500
> Subject: Adding zlib to libwww applications
> 
> Hi, All,
> 
>    I am adding zlib to my libwww applications. Does anyone have a sample to
> show how to use those functions in HTzip.c ?
> 
> Ailleen Lien

Hi Ailleen,

Sorry this is such a late reply but in fact I myself did not look into
adding
zlib support into my libwww client until now. I thought I would send a
brief
comment on what I found in case this is useful for anyone else.

Perhaps a more senior developer from the libwww project could correct me
if I am wrong
but as far as I can tell, the current HTZip.c (as of libwww 5.3.2) only
leverages the
zlib library to add inflate support for the "deflate" Content-Encoding.
Although it mentions compress/uncompress in some of the headers I
believe all that
currently is setup by HTInit.c is the registering of the HTCoder
HTZLib_inflate
function.

So I do not belive that Content-Encodings like "gzip" or "compress" will
work
'out of the box' unless someone writes an equivalent HTZLib_inflate for
these 
encodings?? (at least as far as my tests went, only 'deflate' was
recognized)
This actually makes sense because when I inspected what my libwww client
sends
as headers on HTRequests I would see: Accept-Encodings: deflate
because that the only compression encoding registered in HTInit.c

Ok, so basically what does this mean for libwww clients that want to
'use zlib'?

The good news is that it does not involve any code change for the libwww
client. The library will simply see a header of 'Content-Encoding:
deflate' and automatically
wrap in the inflate stream and inflate the contents of the response for
you, handing
you the response data as your client would normally expect it in its
uncompressed state.
It would basically be the server that compresses and sends your libwww
client the
compressed data while the zlib support in libwww automatically inflates
the data for you on the client.

As an example, I use libwww in a client application that sends and
receives XML to a Java servlet
on a web server. Up to now I have simply been sending the XML back and
forth as standard
UTF8 uncompressed text. However, in Java it is extremely easy to simply
decide to send the XML back to my client 'deflated', as in the following
snippet of sample code:

    ...
    ByteArrayOutputStream byteOut = new
ByteArrayOutputStream(DEFAULT_BUFFERSIZE);
    Writer writeOut = null;
    DeflaterOutputStream dout = null;
    if (deflating) {
      dout = new DeflaterOutputStream(byteOut);
      writeOut = new OutputStreamWriter(dout, "UTF8");
      response.addHeader("Content-Encoding", "deflate");
      }
    else {
      writeOut = new OutputStreamWriter(byteOut, "UTF8");
      }
    writeOut.write( xmlOut.toString());
    writeOut.flush();
    // Once you call finish on deflating one cannot write anymore
    if (dout != null) dout.finish();
    ...

Notice the only difference between sending the original uncompressed XML
and deflated XML
is to wrap the outputstream with a java.util.zip.DeflaterOutputStream
output stream,
add the Content-Encoding: deflate header to the response, and call
finish() on the deflater stream to
make sure that it completely finishes all compression before you send
the response back.

Granted this is Java code but you would essentially do the same thing in
an alternative  
language on your server.

The great thing is that your libwww client will automatically handle the
inflate of
the data without the need to add any new code to know whether the data
is compressed or not.

By the way, some initial results of using this in my app when I might
have larger chunks
of XML coming from the server show up to a 4x compression factor on the
response data and no noticable
delay because of the compression on the server and the decompression on
the libwww client.

Hopefully this info might save you some time in development if you want
to try and
leverage the zlib support in libwww.

Take care,
Jeff Adams
Received on Monday, 19 February 2001 10:20:36 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 23 April 2007 18:18:38 GMT