>> My question is, will it be possible to add a configuration option to turn
>> off these content mutating handling?
>
> I can't say I agree that they are "content mutating", but apart from that
and
> since others have previously asked for something similar regarding the
chunked
> transfers, I can't see that I would mind a clean approach that let libcurl
do
> this. Just be aware that it still needs to parse all the chunks (and chunk
> trailer) properly so that libcurl knows when the response ends.
>
What do you think of this approach then:
1. a new CURLOPT option (something like HTTP_RAW_DATA ?)
2. in http_chunks.c and content_encoding.c override the calls to
Curl_client_write (and probably some of the processing which would be
redundant) with calls that pass the raw data.

>> Especially if you do want (like I occasionally do) to process the
response
>> body prior to returning it to the user or benefit from connection reuse.
>
> If you process it before you return it to the client, then why not remove
the
> chunked-transfer header and add a content-length and send back the whole
body
> in a non-chunked way? It would save you from having to re-implement the
> chunked decoder yourself...

In my scenario I prefer to pass all the response headers and body as is.
When following your suggestion, one would be forced to recalculate the new
content-length and wait until the entire response is received and processed
by curl prior to sending it to the client. If only raw data is transfered by
curl, one can work in a "streaming" mode and send the data to the client as
it is received.

Cheers,
Shmul
Received on 2007-01-29