Hi Patrick, On Sat, May 25, 2019 at 10:38:35AM -0400, Patrick Hemmer wrote: > > 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.
Yes definitely, my question was more related to the use cases you were facing :-) > 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. Theorically it is even permitted to move them from trailers to headers if they are received in time (e.g. from a cache). But I'm not aware of any component doing this. > 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. OK, so that's definitely an argument for using the same methods from a configuration perspective. Could you please do me a favor and file a feature request in the github issue tracker about this point and with a link to this discussion ? This way we don't risk forgetting about it. Thanks! Willy
