3 ms·

gRPC needs access HTTP/2 trailers, which is not supported in browsers today. This necessitates translation in a proxy of some form. It is possible to support in

gRPC needs access HTTP/2 trailers, which is not supported in browsers today. This necessitates translation in a proxy of some form. It is possible to support in-process or local proxies, but instead starting with this in n languages, we are starting with a proxy, with the intention to build in-process support on languages or use cases where there is real need for it.

thwd 8y ago
Note that trailers have existed since HTTP 1.1.
- puzzle 8y ago
  Yeah, but a lot of software does not support them, at all levels in the chain. Which is a tragedy. They'd be useful in more contexts than just gRPC.
- chrissnell 8y ago
  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.
  - mentat 8y ago
    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.
    - aktau 8y ago
      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.
jondubois 8y ago
I never understood why gRPC decided to use HTTP2 instead of WebSockets. WebSockets is a much simpler protocol and is the closest you can get to raw TCP sockets in the browser. HTTP was designed for file downloads and uploads while. WebSockets was designed for raw data.

thwd 8y ago

Note that trailers have existed since HTTP 1.1.

puzzle 8y ago
Yeah, but a lot of software does not support them, at all levels in the chain. Which is a tragedy. They'd be useful in more contexts than just gRPC.
chrissnell 8y ago
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.
- mentat 8y ago
  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.
  - aktau 8y ago
    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.

jondubois 8y ago

I never understood why gRPC decided to use HTTP2 instead of WebSockets. WebSockets is a much simpler protocol and is the closest you can get to raw TCP sockets in the browser. HTTP was designed for file downloads and uploads while. WebSockets was designed for raw data.