Re: Chunked transfer coding

>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.

>frystyk@w3.org replied:
>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
>
>    http://www.w3.org/Library/src/HTInit.html
>
>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.

OK, this issue is now *hot* in our project. The application begins
generating a stream of data that it wished to write/post/put to the server.
It calls my "start writing" routine. I then <<do some magic libwww calls>>
and write the first piece of data to the server. Then I return to my
caller. The caller then calls me repeatedly to write more data to the
server which I am to oblige by <<doing some more magic libwww calls>>. (And
here comes what I consider the *real* problem. My caller, the writer of all
this data, finally decides that all the data has been written. He wants to
do two things. The second thing he will do is call me indicating that he
would like to close the stream. I will <<do some magic libwww calls>> to
tell the server that the URL is finished being written/posted/put. That, at
least, seems to be doable using chunked transfer encoding under HTTP/1.1.
The *first* thing the caller wishes to do, however, is difficult. At the
point that he decided to close the stream, he also knew some data that
should be written AT THE FRONT OF THE STREAM. For instance, he now knows
the size of the stream and wishes to write that size at the beginning of
the stream. So the stream needs to be positionable in order for data known
at close time to be written back to the front of the stream. Currently,
this is all trivial using positionable files in the filesystem. The
requirement is to implement the same functionality over HTTP/1.1.

From reading about HTTP/1.1. I thought it was possible to use ranged PUTs,
that is, PUTs with CONTENT-RANGE headers, to position the server within the
URL being PUT. If I can't do that, is there a more acceptable way to get
the front of the URL rewritten?

Should I use POST somehow, instead?

I also assume I could require that my servers handle ranged PUTs, and just
be done with it, but I'd like to find a way to use "normal" HTTP/1.1 to get
a URL written and then updated at its beginning.

Ideas? Suggestions? Experiences?

regards,
-jim

Received on Wednesday, 13 January 1999 12:27:42 UTC