Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why does gRPC insist on trailers?

carlmastrangelo.com

Post reply on HN
Print view View original

41–50 of 136 posts

Re: Why does gRPC insist on trailers?

#41

Post by Matthias247 »

> In this flow, what was the length of the /data resource? Since we don’t have a Content-Length, we are not sure the entire response came back. If the connection was closed, does it mean it succeeded or failed? We aren’t sure.

I don’t get that argument. GRPC uses length prefixed protobuf messages. It is obvious for the peer if a complete message (inside a stream or single response) is received - with and without trailers.

The only thing that trailer support adds is the ability to send an additional late response code. That could have been added also without trailers. Just put another length prefixed block inside the body stream, and add a flag before that differentiates trailers from a message. Essentially protobuf (application messages) in protobuf (definition of the response body stream).

I assume someone thought trailers would be a neat thing that is already part of the spec and can do the job. But the bet didn’t work out since browsers and most other HTTP libraries didn’t found them worthwhile enough to fully support.

Re: Why does gRPC insist on trailers?

#43

Post by modeless »

twiss wrote: post #28

> 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…

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.

Re: Why does gRPC insist on trailers?

#44

Post by adev_ »

xyzzyz wrote: post #34
adev_ wrote: post #29

Earlier quoted context omitted.

> The author convinced they're needed. But I wonder if some sort of error signaling should have been baked into `Transfer-Encoding: chunked` instead. It wouldn't have made sense in HTTP/1.1 since you can just close the connection. But in later HTTP versions with pipelined requests, I can see the use for bailing on one request while keeping the rest alive. It did not to me. I would rephrase the argumentation as: - In…

> Like the Head-of-Line blocking problem: it is not solved in HTTP/2 How so? It is not solved on the network level (due to its use of TCP), but it is solved on application layer: slow response to one request is not blocking other requests.

> How so? It is not solved on the network level (due to its use of TCP), but it is solved on application layer: slow response to one request is not blocking other requests.

Like you said, it does not solve the network level:

- in HTTP/2, A packet drop will slow down every HTTP transaction.

- In HTTP/1 with a session pool (The usual web browser way of doing thing), it will slow down only one over X (X, size of the pool).

This has been found to be a big problem over (unreliable) mobile network and that makes HTTP/2 sometimes even worst than HTTP/1.

http://nl.cs.montana.edu/lab/publications/Goel_H2_extended.p...

Re: Why does gRPC insist on trailers?

#45

Post by stefan_ »

Matthias247 wrote: post #39
remram wrote: post #3

> As an aside, HTTP/2 is technically superior to WebSockets. HTTP/2 keeps the semantics of the web, while WS does not. WTF is this? Those are different layer protocols. WebSocket can run on top of HTTP/2. It's like saying TLS is technically superior to TCP, or IP is superior to copper cables. Reference: https://www.rfc-editor.org/rfc/rfc8441.html

The idea here is that http provides something like request/response semantics, methods, path, status code, etc - which are all also useful for gRPC. Websockets provide none of that - they are just message streams. Websockets over http/2 are a new thing, and haven’t even been available at the time gRPC incepted.

That is their whole point. That is why they exist. Dumb reliable pipe, please keep your silly semantics away.

Re: Why does gRPC insist on trailers?

#46

Post by fijiaarone »

twiss wrote: post #28

> 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…

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.

Re: Why does gRPC insist on trailers?

#47

Post by afc »

Matthias247 wrote: post #41

> In this flow, what was the length of the /data resource? Since we don’t have a Content-Length, we are not sure the entire response came back. If the connection was closed, does it mean it succeeded or failed? We aren’t sure. I don’t get that argument. GRPC uses length prefixed protobuf messages. It is obvious for the peer if a complete message (inside a stream or single response) is received - with and without trai…

He offers two facts that I think explain this well enough:

> Additionally, they chose to keep Protobuf as the default wire format, but allow other encodings too.

And:

> Since streaming is a primary feature of gRPC, we often will not know the length of the response ahead of time.

These make sense; you'd enable servers to start streaming back the responses directly as they were generating them, before the length of the response could be known. Not requiring servers to hold the entire response can have drastic latency and memory/performance impact for large responses.

Re: Why does gRPC insist on trailers?

#48

Post by twiss »

modeless wrote: post #43
twiss wrote: post #28

> 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…

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 featu…

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

Re: Why does gRPC insist on trailers?

#49

Post by mdriley »

It seems like a lot of other technologies in this space have solved the listed problems while remaining compatible with browsers, load balancers, reverse proxies, etc.

It was a product choice not to offer a fallback path when HTTP/2 was unavailable. That choice made gRPC impossible to deploy in a lot of real-world environments.

What motivated that choice?

Re: Why does gRPC insist on trailers?

#50

Post by teaearlgraycold »

AceJohnny2 wrote: post #32

Offtopic, but: > However, Google is not one single company, but a collection of independent and distrusting companies. This is an important thing to keep in mind when considering the behavior of any large company.

As a Googler, it's worse. Even within one of the "companies" there is distrust in the chain of command.
Post reply on HN