[twiss]

> Whether it’s because I was wrong, or failed to make the argument [for HTTP trailers support], I strongly suspect organizational boundaries had a substantial effect. The Area Tech Leads of Cloud also failed to convince their peers in Chrome, and as a result, trailers were ripped out [from the WHATWG fetch specification].

FWIW, I personally think it's a good thing that other teams within Google don't have too much of an "advantage" for getting features into Chrome, compared to other web developers, however, I also think it's very unfortunate that a single Chrome engineer gets to decide not only that it shouldn't be implemented in Chromium, but that that also has the effect of it being removed from the specification. (The linked issue [1] was also opened by a Google employee.)

Of course, you might reasonably argue that, without consensus among the browsers to implement a feature, having it in the spec is useless. But nevertheless, with Chromium being an open source project, I think it would be better if it had a more democratic process of deciding which features should be supported (without, of course, requiring Google specifically to implement them, but also without, ideally, giving Google the power to veto them).

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

[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.

[sneak]

Why should the decisionmaking process for Chromium be “democratic” simply because it is open source?

Anyone who wants to pay can implement whatever they want in the codebase. That’s in a way as democratic as it gets: equality of opportunity [to invest money and time].

If Google is paying for the implementors’ time, Google should have 100% say in what code they write. You and everyone else are free (thanks to Google’s generosity) to fork it at any point in the commit history and individually veto any specific change.

[twiss]

> Anyone who wants to pay can implement whatever they want in the codebase. That’s in a way as democratic as it gets: equality of opportunity [to invest money and time].

Leaving aside whether that's how it should work, I'm not sure if that's in fact how it works for Chromium today. If I write a high-quality patch adding support for trailers, will it get accepted? As I understand it, the answer is no. (But I would be happy to be wrong.)

So that's my main point: it would be good to have a democratic decision making process, not for what code Googlers should write, but for what patches would get accepted into Chromium. Not just because it's open source, but also because it's the basis not just of Google's browser, but a bunch of other browsers as well.

(And note that https://www.chromium.org/ seemingly aims to give the project an air of independence from Google. Thus, I'm merely questioning whether it is, in fact, independent, and arguing that it should be, if it isn't.)

[Brian_K_White]

The democratic process is that anyone who wants to pay for the ad campaign can try to convince everyone else that it's a good spec everyone should adopt, not merely pay a developer to code it.

If everyone else is not convinced then it should not become a thing no matter how much one party with money wants it.

[fijiaarone]

I wanted my road to swoop up and down like a roller coaster across the gorge but a single structural engineer on the bridge team overruled my obvious benefit.