proposal: net/http: add HTTP transport interceptors

[ngochd7]

Proposal Details

Proposed new Transport Interceptor Api for net/http package.
It helps users easily install hooks/filters/custom_actions into their Http Client.
A few use cases that I'm using and that I think are useful to a lot of people:

• Block calls to unwanted hosts.
• Add default header for all requests.
• Intercept the Http Request to the destination and send the Mock Http Response to the user. (Useful for Testing)
• Collect complete information about the Request and Response of every Http Request.
• ...

I have written a few typical Interceptors here, you can see it is quite clear so users can easily use and create their Interceptors.

[ianlancetaylor]

CC @neild @bradfitz

[neild]

It doesn't seem like there's anything here that needs to be in the net/http package. The examples all seem to wrap an http.RoundTripper with middleware.

I'd suggest developing this as a regular package outside the standard library.

[ngochd7]

I do not think so: The examples all seem to wrap an http.RoundTripper with middleware:

• This is Interceptor I was defined: type TransportInterceptor func(req *Request, resp *Response, roundTrip func(*Request, *Response) error) error, you can see that the roundTrip parameter has a different design than http.RoundTripper (This is the core peculiarity of what makes my chain interceptor function work so well.)

Reply: I'd suggest developing this as a regular package outside the standard library.

• I got the idea of building an Interceptor from the grpc-go library. In that library, the Interceptor is used quite a lot when installing a grpc-client and I think this similarity can be deployed with an http-client.
• I find it quite useful for many users to know when it is integrated into Core instead of an external library. In addition, the source code added here is quite small. I think adding it to Core will be more reasonable than creating an external library.

[leaxoy]

Dup with #38479

[Jorropo]

I agree
They could be different if #66844 proposed an API and it was different.

[neild]

In addition, the source code added here is quite small. I think adding it to Core will be more reasonable than creating an external library.

The bar for adding new features to the standard library is high. In general, anything new in std must have a very compelling reason why it should be there and not anywhere else. "It's small and someone might use it" isn't enough.

See also: https://go.dev/doc/faq#x_in_std

[ngochd7]

@neild ne
Thank you, maybe I understand the problem. I will close this Proposal.