http.Response.Body.Close when ignoring the resp

[James Bardin]

I feel like I've seen it mentioned somewhere that you don't need to close an http.Response.Body if you didn't use the response. 

But, I can't find that anywhere in the official docs.

The docs say (currently) "Caller should close resp.Body when done reading from it",  but there's no mention that resp.Body *must* be closed.

Am I mis-remembering something, or is

    _, err := http.Get(url)

not supposed to leak connections?

[Jesse McNelis]

Something has to be done with the data waiting to be sent to you on
the connection.
Calling .Close() on the Response.Body tells the http.Client to read
the data from the connection and discard it(or to close the connection
if the amount to read is too large)

It's very unusual to make a http.Get() request and not be interested
in the result.

[James Bardin]

Sorry, yes I'm aware of all this.

This came up because of some code that wasn't closing the Body when the resp.StatusCode wasn't acceptable. The fix was to close the Body, but after having seen that code, it made me think that I had once heard that you didn't need to close the Body if it's not Read. 

But if there's no one to corroborate by hallucination, it must have been just that ;) 

[Eli Janssen]

I believe you have to actually read the entire body yourself — with something like io.Copy + ioutil.Discard if
you don’t care about it.
If you just call response.Body.Close() without reading till EOF, the conn is just closed and discarded (not reused).

http://golang.org/src/pkg/net/http/transport.go#L869

[James Bardin]

On Tue, Sep 16, 2014 at 8:51 PM, Eli Janssen <el...@wundrd.net> wrote:

If you just call response.Body.Close() without reading till EOF, the conn is just closed and discarded (not reused).

Yeah, and that's definitely worth bringing up here in for other's who may stumble upon this thread. If you didn't consume the entire response, the server is in an unknown state, and you can't reuse the connection. 

[Philippe Lafoucrière]

I had the same issue. I was not reading the body in most cases (only if there's an error, otherwise the body is an empty string on the distant API).

I was leading to leaking open files on the server, so I confirm, you MUST close the body, even if you don't read it :)

[time...@gmail.com]

that's for sure. I has same issue, IF you don't close the body even you don't care about that, the file descriptor won't close and lead to "too many open file" error

在 2014年9月17日星期三 UTC+8下午3:28:34，Philippe Lafoucrière写道：

[Andreas Götz]

Replying here as I was thinking about suggesting a go/vet check if the body is actually being closed. 

What I realise now is, that closing the body is just as good as not closing it as long as one doesn't read it first. As for reading there is probably a trade-off on when actually reading is still faster than establishing a new connection, either in latency or just cpu cycles/ power consumption.

Given that- I'm wondering if it weren't proper advise to just NOT care about closing the body unless you know for sure that you're interested in keep alives?

Cheers,

Andi