W3C home > Mailing lists > Public > www-lib@w3.org > October to December 1998

Re: Chunked transfer coding

From: Henrik Frystyk Nielsen <frystyk@w3.org>
Date: Tue, 22 Dec 1998 12:26:23 -0500
To: www-lib@w3.org
Message-ID: <367FD63F.E8C9F1FE@w3.org>
To: Jim_Ravan@avid.com

Jim_Ravan@avid.com wrote:
> As you all can see from the above, we have been talking about chunked
> transfer coding. Has anyone successfully sent and received chunked
> transfers using libwww? Can anyone tell me how to do it? I've looked at the
> code for hours now, and I'm stuck. The mechanism for getting the transfer
> encoding and decoding to happen is just a little too opaque for me to
> figure out.

libwww can certainly decode and encode chunked transfer codings - this
is set up when using one of the default profiles, see the "Default
Transfer Encodings" in


However, this won't solve the problem of doing PUT with byte ranges. It
didn't go into HTTP/1.1 as it is too unreliable - you never know whether
the server handles byte ranges or not and it makes a big difference
whether you patch or override the resource.

It is currently on the plate of Webdav but I checked the authors there
and they haven't gotten to it yet. There is therefore no solid way of
handling PUT with byte ranges yet.
> The basic idea on my output side - my layer has both output and input, but
> the current issue only concerns output - is to have my callers ask me to
> start a transfer with the first piece of data they hand me. I would issue
> some yet-to-be-determined set of libwww calls and send the first chunk of
> the chunked transfer. I would then return to my callers. They would then
> pass me <n> additional pieces of data over time which I would continue to
> send as chunks in the current chunked entity. Then they would tell me that
> they were finished sending the current entity, and I would send a final "0"
> chunk to signal the end of the chunked transfer. This seems to me to be
> pretty much how HTTP/1.1 envisioned chunked transfer encoding should
> happen, but for the life of me, I can't figure out how to get libww to do
> it.

Both input (from app to network) and output (from network to app) are
streams in libwww. For output streams, the data generator is the network
read loop, but for input streams, the app must provide the data which is
going to be sent over the network.

As always, libwww is flexible and supports multiple data generators -
they are dynamically registered in the HTRequest object, see section
"Sending data to the Network" in


For the partiular case of HTAccess, this module (which provides the
highest level libwww API) has its own implementation called

However, this assumes that the application knows how much data it wants
to upload. If the application has a dynamic set of data then it has to
provide the loop itself.

Received on Tuesday, 22 December 1998 12:26:26 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:33:48 UTC