How are response trailers managed? #3620
-
Hello, I am developing a small gRPC proxy using Whevener the proxy responds by forwarding the response, it works as expected. However, as soon as the response is buffered, I get this error on the client side:
Here is the part of the code: pub async fn forward(request: Request<Body>) -> Result<Response<Body>, hyper::Error> {
let forwarded_request = ...;
let client = Client::builder().http2_only(true).build_http();
let response = client.request(forwarded_request).await.unwrap();
// Getting a "server closed the stream without sending trailers" error from client with this
// let (parts, body) = resp.into_parts();
// let body_bytes = hyper::body::to_bytes(body).await.unwrap();
// let response = Response::from_parts(parts, Body::from(body_bytes));
Ok(response)
} I am not familiar with what trailers are. The initial request has a "te": "trailers" header, so I am guessing my response is missing something when it is buffered by the proxy. Are "trailers" something I can inspect in an Thanks in advance! |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 2 replies
-
The trailers are basically "headers" that come at the end of the body. They sorta exist in HTTP/1.1, but are a better supported thing in HTTP/2 and 3, so gRPC uses them to indicate the "status" of a message. hyper (0.14.x) exposes them in the body as However, gRPC makes heavy use of streaming bodies, so you might find buffering till the end in a proxy causes problems. Some gRPC services assume they can send a message sporadically or on an interval, and expect a streamed reply back, such that buffering would disrupt that. |
Beta Was this translation helpful? Give feedback.
The trailers are basically "headers" that come at the end of the body. They sorta exist in HTTP/1.1, but are a better supported thing in HTTP/2 and 3, so gRPC uses them to indicate the "status" of a message. hyper (0.14.x) exposes them in the body as
poll_trailers()
. If you make use ofhyper::body::HttpBody
, the trait, there's a replacement forto_bytes()
, which isHttpBody::collect()
. It will also have collected the trailers (to_bytes()
just tosses them).However, gRPC makes heavy use of streaming bodies, so you might find buffering till the end in a proxy causes problems. Some gRPC services assume they can send a message sporadically or on an interval, and expect a streamed reply back, …