And I have added the HeadersOverwrite Option by myself.
I'm glad to create a PR if needed.

CC @neild

I add a custom way to modify headers,
and this is my commits.
I will create a PR if welcomed.

master...LawyZheng:master

It sounds like maybe this is a duplicate of the more general problem in #50465?
And #50465 is pretty intractable at the moment unfortunately.
We probably need a whole new proxy API.

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

In my understanding, I don't think it is a duplicate problem in #50465.
#50465 seems to talk about the headers in the request to track where the request is coming from,
while this issue is trying to talk about the headers in the response.

http allows for headers to be specified multiple times for headers that can be combined with a ,

from rfc 2616

Multiple message-header fields with the same field-name MAY be present in a message if and only if the entire field-value for that header field is defined as a comma-separated list [i.e., #(values)]. It MUST be possible to combine the multiple header fields into one "field-name: field-value" pair, without changing the semantics of the message, by appending each subsequent field-value to the first, each separated by a comma. The order in which header fields with the same field-name are received is therefore significant to the interpretation of the combined field value, and thus a proxy MUST NOT change the order of these field values when a message is forwarded.

For example, duplicate headers are often used for X-Forwarded-For instead of combing them into a comma separated list.

In a response, a good example of using a header multiple times is to set multiple cookies with Set-Cookie, in which mozilla advises:

To send multiple cookies, multiple Set-Cookie headers should be sent in the same response.

http allows for headers to be specified multiple times for headers that can be combined with a ,

from rfc 2616

Multiple message-header fields with the same field-name MAY be present in a message if and only if the entire field-value for that header field is defined as a comma-separated list [i.e., #(values)]. It MUST be possible to combine the multiple header fields into one "field-name: field-value" pair, without changing the semantics of the message, by appending each subsequent field-value to the first, each separated by a comma. The order in which header fields with the same field-name are received is therefore significant to the interpretation of the combined field value, and thus a proxy MUST NOT change the order of these field values when a message is forwarded.

For example, duplicate headers are often used for X-Forwarded-For instead of combing them into a comma separated list.

In a response, a good example of using a header multiple times is to set multiple cookies with Set-Cookie, in which mozilla advises:

To send multiple cookies, multiple Set-Cookie headers should be sent in the same response.

Yes, I can't agree with you anymore.
Maybe I didn't explain my proposal clearly in the title and content,
I don't mean that we should use replace instead of append,
I'd like to say that we are able to choose the method we want when we use ReverseProxy.

It seems clear that ReverseProxy is not right in certain contexts, but we don't know the right path forward for it.

Perhaps the right next step is to put this on hold (or decline it) and suggest that people fork ReverseProxy and experiment in their own copies?

Maybe I didn't explain my proposal clearly in the title and content

I think it's I who did not read your proposal accurately

I personally have no objection to the patch supplied, but I am curious why it can't be handled in ModifyResponse(*http.Response)? -- for example, to remove headers that you don't want propagated. It looks like headers get copied only after ModifyResponse has been called. t's probably less error prone and more ergonomic to think in terms of what headers to copy, versus what to remove so it isn't copied.

Another thought: I personally find myself reaching for httptest.ResponseRecorder, or similar http.ResponseWriter implementations to do things like capture upstream response codes, headers, or body.

I think if the standard library had a simple http.ResponseRecorder that didn't make some of the choices that httptest.ResponseRecorder does, then a lot of situations like this wouldn't be as painful, because they could easily have a middleware in front of them to capture/rewrite headers as necessary.

That's not a perfect solution either, because it likely means that the reverseproxy response needs to be buffered, which may be undesirable, especially for larger requests.

for example, to remove headers that you don't want propagated. It looks like headers get copied only after ModifyResponse has been called.

Actually, I've solved this problem in this way now. But I don't think it's a good solution, because it feels like solving this problem as a special case in certain special requests, rather than solving it from a project common perspective.

For example, I need to make sure three things (the middleware, ReverseProxy, response headers which I care about) are compatible with each other to handle the request correctly. From my personal view, I don't think it's a good way for project maintenance.

As you mentioned, many frameworks will not buffer the HTTP body considering the performance, which means the middleware will write the headers before ReverseProxy does. So maybe it's better to implement it in the ReverseProxy struct?

Just my personal opinion.

It seems like we should decline this until we have a clearer idea of a path forward (or a new package).

Based on the discussion above, this proposal seems like a likely decline.
— rsc for the proposal review group

No change in consensus, so declined.
— rsc for the proposal review group