Decide wether Interceptors can mutate all headers about connect-go HOT 3 CLOSED

Huh, that's a good point - I hadn't thought of that class of use cases at all. Makes sense to me, plus it removes another exported type.

@amckinney, what do you think?

from connect-go.

Authentication is a great example on the handler side. As for call interceptors, it's a little harder to come up with a practical example.

But, I suppose an observability interceptor might be used to emit metrics and/or logs for some response header(s), then strip them once they're finished. Additionally, a call interceptor might perform additional checks and set a response header so that a retry interceptor earlier in the chain is triggered (i.e. "if a specific response header is set, retry the request").

My examples aren't as compelling as the one @severb described, but I think the point stands: we shouldn't prevent a user from customizing their interceptor chain in any way they please. If the user wants to mutate these values, they should feel empowered to - it's their application, after all.

It's simpler on our end to have a single, mutable Header type, so I'm in favor of consolidating the {Immutable,Mutable} types.

from connect-go.

SGTM.

from connect-go.