CC @neild @bradfitz

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.

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.

Dup with #38479

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

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

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