undefined | Better HN

0 pointstwiss3y ago0 comments

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

0 comments

modeless3y ago

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.

twissOP3y ago

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.

raggi3y ago

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.

paulgb3y ago

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.

raggi3y ago

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.

Matthias2473y ago

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.

raggi3y ago

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

j / k navigate · click thread line to collapse

0 pointstwiss3y ago0 comments

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

0 comments

modeless3y ago

twissOP3y ago

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.

raggi3y ago

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.

paulgb3y ago

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.

raggi3y ago

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.

Matthias2473y ago

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.

raggi3y ago

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

j / k navigate · click thread line to collapse