Thanks for reply!
@ijp: Yes, I think return received data within exception is ugly. But I have to do it because my consideration is to return received data when *any* exception happens. So if it's not a common connection error, I have to catch it to return the received data, then re-throw the same exception(and cut the received data). Because other program may expect this exception. But I don't claim that this is the best design. Anyway, just a proposal.
@Daniel: I realized that seems make "get-bytevector-n" return the received data rather than read-response-body is better. But I'm afraid that it'll conflict with the definition "get-bytevector-n". Say, we ask for n bytes, but it returned m bytes less than n. So the user maybe get confused with the name "get-bytevector-n".

On Fri, Mar 16, 2012 at 2:48 AM, Daniel Hartwig <mandyke@gmail.com> wrote:
On 16 March 2012 02:37, Ian Price <ianprice90@googlemail.com> wrote:
> Daniel Hartwig <mandyke@gmail.com> writes:
>> For example, reusing the same bytevector and looping over
>> read-response-body! saving the results to disk each time.  This limits
>> the memory use to the size of the bytevector *and* removes the copy
>> operation from your implementation (bonus!).
> If you wanted to do it that way, it'd be better to pass in the port
> directly and cut out the middle man.
>

Indeed.  The procedure shown is similar to one from one of my own
projects which features the write-to-disk internally.

I guess it pays to keep in mind that it is trivial to rearrange
procedures such as this to suit any particular situation.  The OP
appeared--to me--to be very over worked for the task.

Perhaps such error-tolerance/streaming capabilities can be tied in at
a level closer to get-bytevector-n...


Regards