Hi all,

I currently think about the use case where compressed content is
requested by the client in ranges of a certain size, so that multiple
requests for different ranges are needed to get the complete data. After
all the (compressed) data was received, it has to be decompressed.

My current understanding of the sequence is as follows

1) Client requests the first range (e.g. 0-99) of a resource. The
Accept-Enconding header is set to GZIP.
2) Server receives request of client and sees that the client accepts
GZIP compression. It then
     compresses the complete ressource (e.g. 10000 bytes which result in
1000 bytes GZIP compressed data) and stores
    the compressed data temporarily. The servers returns the first 100
bytes of compressed data to the client.
3) The clients saves the first 100 bytes to temporary storage and
requests the next 100 bytes. The client knows about the compressed data,
because the Content-Encoding header in the response is present and set
to GZIP.
4) After the client has received the 1000 bytes of compressed data it
uncompressed and data which results in the 10000 bytes of (uncompressed)
data which is stored on the server.

And know the questions:
1) How does libCurl deal with compressed partial data (HTTP response
code 206) ? According to the documentation there is some sort of
"automatic" decompression. How does this work in detail when the
CURLOPT_WRITEFUNCTION callback is used for data reception?
2) I have the same use case but in the other direction. Compressed data
should be uploaded in parts. Does libCurl provide here also some
automation or does the libcurl client has to do the compression first
and send send the data in appropriate data segments?

Many thanks for your advice,

Stefan
Received on 2007-04-30