support response body stream

[Anthony-Dong]

why:
When developing HTTP proxy tools, we encountered the need to forward large packets, and the second is to support streaming forwarding, so we need to modify the sdk.

For security reasons,Response.BodyStream() function return io.ReadCloser and lets the user manually release the resource .

Finally, I want request to support stream and open it up to developers.

[erikdubbelboer]

Looks good at a first glance, I still have to take a deep look at it.

[byene0923]

i'm also look deep into it, i think the code can be more elegant, do you think use Requeststream in response is a good way?

[Anthony-Dong]

i'm also look deep into it, i think the code can be more elegant, do you think use Requeststream in response is a good way?

I think it's just a naming issue, since request stream was already supported.

[byene0923]

i'm also look deep into it, i think the code can be more elegant, do you think use Requeststream in response is a good way?

I think it's just a naming issue, since request stream was already supported.

you could change the name such as bodyStream

[Anthony-Dong]

@erikdubbelboer do you have any questions ?

[erikdubbelboer]

Why is this sync.Once needed here? If Close can be called multiple times, shouldn't closeFunc then also not be able to be called multiple times?

[Anthony-Dong]

if SetBodyStream is true, the clientConn does not immediately close. need to close it manually. close clientConn does not need to be executed multiple times.

[Anthony-Dong]

For example, sync.Pool has the same object and clientConn is closed multiple times

[erikdubbelboer]

I'm not sure I understand. Can you show how Close would be called multiple times?

[Anthony-Dong]

I thought it wouldn't be good to return an io.ReadCloser directly, so I added the CloseBodyStream method @erikdubbelboer

[erikdubbelboer]

I did some investigating into this issue, #1504, and it seems it is cause by Close being called multiple times. So I understand the sync.Once now. But I'm wondering if we should fix the double close instead.

[Anthony-Dong]

perIPConn#Close() method is also wrapped in sync.Once ? It also seems reasonable and easier to deal with

[Anthony-Dong]

Whether the client end is used out needs the same processing, I think it depends on whether there is concurrent execution of closeBodyStream. If there is, the same problem will indeed occur, but this is an unreasonable use behavior, not a framework defect. @erikdubbelboer

[Anthony-Dong]

i'm also look deep into it, i think the code can be more elegant, do you think use Requeststream in response is a good way?

I think it's just a naming issue, since request stream was already supported.

you could change the name such as bodyStream

type responseStream requestStream . might be better

[erikdubbelboer]

Finally had the time to look, looks good. Thanks!