Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

net/http: Client.Do() accepting interface for greater flexibility #40754

Closed
melardev opened this issue Aug 13, 2020 · 6 comments
Closed

net/http: Client.Do() accepting interface for greater flexibility #40754

melardev opened this issue Aug 13, 2020 · 6 comments
Labels
FrozenDueToAge WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided.

Comments

@melardev
Copy link

Hi, in short, what I was looking for is to customize some code from the http.Request object. Since it is a struct and the HttpClient.Do() accepts a struct, we can not, if it was an interface it would be possible.

What version of Go are you using (go version)?

$ go version
go version go1.13.8 linux/amd64

Does this issue reproduce with the latest release?

Yes.

What operating system and processor architecture are you using (go env)?

Not Applicable

// CustomReq is a struct that extends http.Request
req := &CustomReq{}
http.Client{}.Do(req)

Well as we know, Golang has limitations towards OOP, so the above code does not work because *CustomRequest is not considered an *http.Request so it can not be passed to the Do() method.
One solution to these problems in Go is using methods that accept an interface and not a Struct.

Is there any chance to make Do accept an interface and not a struct? I am facing the issue of wanting to customize the bytes being sent in a request(overriding Write()) but since the Do() function accepts an interface I just can't do that.
I think it is not that rare to want to implement our own code but at this time the only way I see to achieve this is to implement the "closest" interface which would be the http.RoundTripper, but that would be too much overhead if I only want to customize the bytes being sent in a request.

@ianlancetaylor
Copy link
Contributor

We can't change the argument type of (*http.Client).Do, as that would break the Go 1 compatibility guarantee (https://golang.org/doc/go1compat).

@ianlancetaylor ianlancetaylor added the WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. label Aug 13, 2020
@melardev
Copy link
Author

melardev commented Aug 13, 2020

@ianlancetaylor Sorry for not being clear, I was obviously not pretending you to change such a core function, that would break any HTTP app, but adding a new set of functions that accept an interface to achieve the same goal(make an HTTP request) but with much more flexibility for people wanting to customize the request bytes without having to reimplement the HTTP stack from scratch.

@ianlancetaylor
Copy link
Contributor

What would the argument type of the new method be?

I don't think it would make sense to define an interface type that just provides methods for all the fields in http.Request. With that many methods, I think it would be simpler for CustomReq to have one method that returns a *http.Request.

@melardev
Copy link
Author

@ianlancetaylor The argument would be an interface, the standard library would have a default implementation, and we, as programmers can change the normal flow by overriding the methods in that interface that would be called at key points in time of the HTTp request lifetime (for example: onWriteRequestBody, onConnection, onResponseClosed, etc.)

@ianlancetaylor
Copy link
Contributor

To me that sounds like a great deal of complexity to add to a package that is already extremely complicated. And it would be very hard to test.

But I'm not a maintainer of the net/http package, so it's not my decision.

@seankhliao seankhliao changed the title HttpClient.Do() accepting interface for greater flexibility net/http: Client.Do() accepting interface for greater flexibility Jun 18, 2021
@seankhliao
Copy link
Member

Closing as there is no concrete proposal here. See also #5465

@seankhliao seankhliao closed this as not planned Won't fix, can't repro, duplicate, stale Jun 12, 2022
@golang golang locked and limited conversation to collaborators Jun 12, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided.
Projects
None yet
Development

No branches or pull requests

4 participants