[modeless]

It's clear that the "single engineer" thing is a lie. Many engineers commented on the Chrome issue with opposing viewpoints, and even the original post describes it being escalated to tech leads on both sides, getting more people involved. I guarantee if it was only one person standing alone opposed to trailers then they would have been overruled. As you say, it's a good thing that Chrome resists adding the pet features of every other Google team to the web.

[twiss]

Sure, that's fair enough. But I'm not sure if characterizing this feature as a pet feature of the gRPC team is accurate either - after all, it's simply exposing an HTTP 1.1 & H2 feature, and it was already in the WHATWG fetch spec. There, the security concerns were apparently discussed as well [1], and adding the trailer headers as a separate object was deemed safe. I haven't read the entire discussion and don't have a vested interest in it, but the WHATWG spec seems like a better place to have this discussion, and come to a conclusion, than the Chromium issue tracker.

Apparently, there is a new issue for it, so that might yet happen: [2].

[1]: https://github.com/whatwg/fetch/issues/34

[2]: https://github.com/whatwg/fetch/issues/981

[modeless]

No other browser has implemented it either. So it's not as though Chrome alone is preventing this feature from existing. It seems likely that other browsers might also take issue with it. It probably shouldn't have been finalized in the spec before being implemented at all anywhere. It may not have been well thought out.

[twiss]

Well, anything is possible, but the original WHATWG fetch issue mentions:

> We discussed this at the HTTP workshop:

> 1. It's okay to expose trailer headers sans semantics in the API and browsers are okay with that.

So it was discussed, and presumably at least well thought out enough that browsers were on board with it. Then, Chrome changed their mind, it was removed from the spec, and yeah, then other browsers didn't implement it either. But I wouldn't call it "likely" that they would have taken issue with it, as there was evidence to the opposite.

[raggi]

This could be solved without trailers by piggybacking on top of server sent events rather than requests with trailers, and terminating a stream with status metadata as a final event.

[paulgb]

The underlying data is binary (protobufs), though. It would defeat the purpose to re-encode it as text to send over SSE.

Also, IIRC gRPC supports full-duplex, which SSE does not.

WebSockets may have been a better fit, as the Chromium developers hinted on the WontFix issue linked in the post.

[raggi]

In the next web, https://web.dev/webtransport/ would be the thing to move to. It's a bit nicer under the hood than websockets, though it's also brand new.

My comment was less about a full duplex replacement though, and more "how to get something equivalent to trailers, that works in browsers today", and this would enable that.

[Matthias247]

Server sent events are just a potential payload format for response bodies, which allows to encode a potentially infinite amount of distinct messages. Trailers are a different concept since they exist outside of bodies.

If the team had decided to only use http body streams for all payload, they could totally have done that without directly using SSE encoding.

[raggi]

SSE adds another thing besides the body encoding, which is a standard content type that implies unbuffered streaming.

[guenthert]

Jeebus. Just because it's not true doesn't mean it's a lie.

[modeless]

It's a lie if OP knows it isn't true. And OP knows it isn't true because they explicitly describe a lot more than one person being involved on both sides.