@atzoum, hello!

Cool, but why not contribute in bodyclose?
Due to the its description:

Analyzer: checks whether HTTP response body is closed **and a re-use of TCP connection is not blocked**.

@atzoum, hello!

Cool, but why not contribute in bodyclose? Due to the its description:

Analyzer: checks whether HTTP response body is closed **and a re-use of TCP connection is not blocked**.

Hi @Antonboom! bodyclose is about closing the body, whereas reuseconn is about both consuming and closing the body and all that happening within a single function.

The reason why reuseconn linter enforces both operations to happen in a single function (separate than the function that performs the HTTP request), is to avoid potential branching logic that can be introduced between the two operations which could result in skipping to consume the body for some of the branches. E.g. it is typical for client code to only attempt to read the response body if the response code is interesting enough (e.g. 200) and skip consuming the body for all other response codes. But, it would be really complex and practically impossible for a linter to verify all such branches consistently through static analysis (or in other words, I am unable to conceive how this could happen!).

That being said, the reuseconn linter promotes the following pattern

func disposeResponseBody(resp *http.Response) {
	if resp != nil && resp.Body != nil {
		// if the body is already read in some scenarios, the below operation becomes a no-op
		_, _ = io.Copy(io.Discard, resp.Body) 
		_ = resp.Body.Close()
	}
}
func main() {
	resp, err := http.Get("http://example.com/")
	defer closeResponseBody(resp) // OK
	if err != nil {
		// handle error
	}
	if resp2.StatusCode == http.StatusOK {
		body, _ := ioutil.ReadAll(resp.Body)
	}
}

With respect to the possibility of extending the original bodyclose linter, indeed this was considered, however, such a change is not backwards compatible, in the sense that it would cause the bodyclose linter to start complaining for most of the code paths that it previously allowed. Thus, IMO such a radically different linting behavior deserves to have a separate linter.

cc @timakin

Hi team, please let me know if there is anything need to be done from my side in order to move this pull request forward

I was also curious why this wasn't PRed upstream to bodyclose since they seem so very closely related. I think backwards compatibility could easily be solved with an opt-in flag (disable by default), is that not an option?

@timakin do you see this as a possibility, merging the 2 linters into one?

btw

1. it is not possible to add an external linter as plugin to golangci-lint if you are using an official executable (link) and
2. it is impossible to customize the golangci-lint-action with respect to the executable that it is running (issue).

If (2) was possible I could compile my own binary with my private linter bundled and use it without bothering you 😄

For me, the right way to move on this PR:

• you have to open a PR on bodyclose or at least an issue
• you have to fix your current PR (checklist and CI)

After I have an idea if there is no reaction from @timakin to handle the duplication problem.

I'm on the same side as @bombsimon .
It's sure verifying whether TCP connection is reused is a definitely good feature.
But as already mentioned by others, it looks just a little bit duplicated with my bodyclose.

I'll be appreciated it if @atzoum opened PR to bodyclose.
Or as an alternative, it's better to clarify both packages' roles.
bodyclose checks whether HTTP response body is closed, and your reuseconn should focus on only checking whether it was reused.

Or as an alternative, it's better to clarify both packages' roles.
bodyclose checks whether HTTP response body is closed, and your reuseconn should focus on only checking whether it was reused.

Checking whether a connection can be reused entails making sure that the body is both consumed and closed. Thus, there will always be some overlapping between reuseconn & bodyclose linters.

I will try to prepare a pull request, however based on my comment here, it is not really straightforward to achieve this for all scenarios that bodyclose covers now, thus my linter was focusing only on enforcing a specific pattern, i.e. expecting both operations to happen in a single function.

@timakin if you have any better idea for implementing this please go ahead