------------------------------------------------------------------------
*From:* Willy Tarreau [mailto:w...@1wt.eu]
*Sent:* Saturday, May 25, 2019, 01:42 EDT
*To:* Patrick Hemmer <hapr...@stormcloud9.net>
*Cc:* Haproxy <haproxy@formilux.org>
*Subject:* Capturing headers from http/2 trailers?

Hi Patrick,

On Fri, May 24, 2019 at 09:00:25AM -0400, Patrick Hemmer wrote:
Is there a way to capture (and log) headers from http/2 response trailers?
The documentation doesn't mention trailers, and when I try to reference
headers which are present in the trailers (e.g. "res.fhdr(grpc-status)"), it
doesn't get captured.

At the end of the day I'm trying to log the grpc-status and grpc-message
headers from gRPC responses.
For now you can't.
Bummer, but thanks for answering.

In fact, in legacy mode, trailers are simply dropped,
and in HTX they're currently encoded in H1 format. Some work has begun
to encode them the same way as regular headers, hoping that in a near
future they can have a more official existence. In this case we could
imagine adding a new analyser which passes after the data forwarding
ones to deal with those, and possibly capture them. Depending on the
complexity this represents we may even possibly imagine backporting
this to 2.0 (e.g. if it's just one analyser triggered in this case).

Based on your experience with gRPC, do you think it would be better to
have different sample fetch functions to look up trailers or to use the
same as the header ones ? My reading of the gRPC spec told me that the
header fields could appear either in headers or trailers sections, which
tends to make me think a unified set would be desirable. But there may
be very valid reasons for prefering to separate them.
The H2 RFC says trailers should be handled as described in RFC7230 chunked trailers section, which goes on to say: > When a chunked message containing a non-empty trailer is received, the recipient may process the fields (aside from those forbidden above) as if they were appended to the message's header section.

So this seems like treating them as one set is acceptable. And with this in mind, any producer of headers/trailers must be prepared for the consumer to treat them this way.

And yes, from my experience on gRPC, the grpc-status & grpc-message headers can appear in both (they appear in headers when there is no body). But these 2 headers have a set purpose and meaning. It doesn't matter which section the header/value came from, it still means the same thing.


Thanks

Reply via email to