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.


Reply via email to