The answer--as I recall--from the Chromium team was that they see trailers access as a security issue. HTTP/2 multiplexes many connections and it was a security risk, they said, to allow one client process to access trailers for connections that may be used by different processes or even entirely different sites behind the same load balancer/reverse proxy/etc.
What I don't understand is why gRPC was designed to depend on trailers. Web gRPC is the killer app for this technology. If they could build a new version of the protocol that doesn't rely on trailers, I would be thrilled.
I believe trailers are because you could start streaming a response and end up having an error than you need to communicate out of band. Hopefully someone has a better answer though.
I've been trying to read the HTTP2 spec and I can't figure out whether it's allowable to return or modify the HTTP(2) status code in a trailer instead of in the header.
After some re-readings, I decided it wasn't allowed.
But then, gRPC definitely needs to be able to signal an error even after it has already streamed data. So gRPC would need to use some end-of-connection message, like a trailer.
What I don't understand is why gRPC was designed to depend on trailers. Web gRPC is the killer app for this technology. If they could build a new version of the protocol that doesn't rely on trailers, I would be thrilled.