Go HTTP package: why do I need to close res.Body after reading from it?

Please see the example here https://pkg.go.dev/net/http#example-Get. The snipped below as well:

func main() {
	res, err := http.Get("http://www.google.com/robots.txt")
	if err != nil {
		log.Fatal(err)
	}
	body, err := io.ReadAll(res.Body)
	res.Body.Close() // Why!?
	if res.StatusCode > 299 {
		log.Fatalf("Response failed with status code: %d and\nbody: %s\n", res.StatusCode, body)
	}
	if err != nil {
		log.Fatal(err)
	}
	fmt.Printf("%s", body)
}

My question is: Why do I need to close the res.Body.Close() in line no 7. I did not open it. I see the explanation in https://stackoverflow.com/questions/33238518/what-could-happen-if-i-dont-close-response-body and I understand that documentation says so.

Could there be a better way of solving this?

I think this is breaking the open/close principle. I think if ReadAll opened the steam it should close it. Is this usually how those things are done in Go?

From the http.Client Do() docs:

> ... If the Body is not both read to EOF and closed, the Client's
> underlying RoundTripper (typically Transport) may not be able to
> re-use a persistent TCP connection to the server for a subsequent
> "keep-alive" request.

In short, if you don't follow this advice, you will accumulate "dead" http connections in your program, as requests are executed - but never cleaned up and/or reused. Your program's performance will degrade overtime - and depending on how many connections are generated - you may exhaust finite resources like file-descriptors that handle network connections.

Have a look at Get func in http package,

func Get(url string) (resp *Response, err error) {
	return DefaultClient.Get(url)
}

it returns a pointer to Response which is a struct containing Body

type Response struct {
        . 
        .
        .
	Body io.ReadCloser
        .
        .
}

dig through the io package source code, you will find out that ReadCloser involves io.Reader and io.Writer. See this

Closing an open Reader would terminate a waiting channel and the underlying goroutine would be closed. Leaving too many of these open channels would block the host os to allocate free processes to the running program which is normally limited to consume a certain amount of processes (it could be altered to devour whole).

The answer to all your questions basically is: Because the documentation says so. That's what documentation is good for. Some things might be "obvious" to you, some not. That's why you read the documentation and follow it.