Log HTTP Request and Response Trailers

[jkotalik]

As a follow up to #31816, we should log Http Request and Response trailers if available.

I see a few potential issues:

• Making sure the trailers are committed before the body is written
• Having a delimiter between headers and trailers?

[JamesNK]

@Tratcher @halter73 @davidfowl

The trick here will be logging them when they are all available and before they disappear. This will be especially true with response trailers. With them you'll need to wait until the response body has finished writing (someone could add a trailer at any time while the response is writing) but before the response ends.

[Tratcher]

Logging the response trailers as the middleware exits should be adequate, it will capture trailers added by anything after it. That does leave a window between this middleware and the start of the pipeline where someone else could add trailers, but that seems like a tradeoff people would be able to understand. In theory you could have the same problem with response headers when there's no body.

Request trailers could be logged when the end of the request body is read (we'll be wrapping the body so we'll know), or when the middleware exits.

Thanks for contacting us.
We're moving this issue to the Next sprint planning milestone for future evaluation / consideration. Because it's not immediately obvious that this is a bug in our framework, we would like to keep this around to collect more feedback, which can later help us determine the impact of it. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[adityamandaleeka]

@wtgodbe @Tratcher Have we seen any demand for this? I'm inclined to move it back to backlog.

[Tratcher]

gRPC would be the main scenario. @JamesNK?