Support WithOutgoingTrailerMatcher

[maja42]

🚀 Feature

grpc-gateway offers the possibility do define custom outgoingHeaderMatcher to decide which grpc-headers should be forwarded as http-headers via a ServeMuxOption. However, grpc trailer-headers are always forwarded in the http-trailers.

In my case, I don't want to forward any grpc metadata to the http API. So I defined a headerMatcher that always returns false. But I can't do the same for trailers. It would be nice to have that possibility.

(As a side note: sending http trailers also removes the Content-Length Header from the response)

[johanbrandhorst]

This sounds reasonable! A side note; we disabled headers altogether for clients that don't include the "TE" header, see https://github.com/grpc-ecosystem/grpc-gateway/blob/v2/runtime/errors.go#L113, but it seems we only disabled it in our error handler, not in our general purpose message handler, see https://github.com/grpc-ecosystem/grpc-gateway/blob/v2/runtime/handler.go#L140. I'd love to have the previous logic added to this section of the code as well, to be compliant with RFC 7230. Would this be enough of a fix for your use case? Would you be willing to add this functionality?

[maja42]

This sounds good, but it doesn't solve my use-case completely. I'd still like to have a outgoingTrailerMatcher.

Reason: We are using the grpc-gateway to provide an external API for our grpc-based microservice architecture. So it acts as a single-point-of-entry and we must be careful about which internal information we want to expose.

We use grpc-headers and trailers to transmit internal information between services, and their content should generally not be exposed via the http API. So even if the browser/user would send a "TE" header (request trailer data), I don't want to return any internal trailer information.

[johanbrandhorst]

Fair enough, sorry for hijacking this issue, I'll change the title and open a separate one for the bug I mentioned.