So as highlighted by
https://github.com/hyperium/tonic/issues/730#issuecomment-895635088 it
turns out the new `Interceptor` trait required changes to tonic-build as
well, which I forgot to publish yesterday. Didn't see it because it wasn't
clear from the commit message.
So this bumps tonic _and_ tonic-build to 0.5.2 so we can release both.
There are no code changes.
`InterceptedService` would previously use `tonic::Request::into_http`
which removes reserved headers. That mean inner middleware in the stack
wouldn't be able to see those headers, which could result in errors.
Fixes https://github.com/hyperium/tonic/issues/700
* Initial compression support
* Support configuring compression on `Server`
* Minor clean up
* Test that compression is actually happening
* Clean up some todos
* channels compressing requests
* Move compression to be on the codecs
* Test sending compressed request to server that doesn't support it
* Clean up a bit
* Compress server streams
* Compress client streams
* Bidirectional streaming compression
* Handle receiving unsupported encoding
* Clean up
* Add note to future self
* Support disabling compression for individual responses
* Add docs
* Add compression examples
* Disable compression behind feature flag
* Add some docs
* Make flate2 optional dependency
* Fix docs wording
* Format
* Reply with which encodings are supported
* Convert tests to use mocked io
* Fix lints
* Use separate counters
* Don't make a long stream
* Address review feedback
Pulls in [hyper-timeout] which has a connector that can have a timeout
applied. I did consider vendoring hyper-timeout since its a fairly small
crate. I guess we can always do that later since its not exposed
publicly.
I would also like to add a test but I'm not sure about the best way of
testing this.
Fixes https://github.com/hyperium/tonic/issues/498
[hyper-timeout]: https://github.com/hjr3/hyper-timeout
Co-authored-by: Lucio Franco <[email protected]>
## Motivation
A gRPC server may send a HTTP/2 GOAWAY frame with NO_ERROR status to gracefully shutdown a connection. This appears to Tonic users as a `tonic::Status` with `Code::Internal` and the message set to `h2 protocol error: protocol error: not a result of an error`.
The only way to currently detect this case and differentiate it from other internal errors (e.g., an application-level internal error) is to match on the message. A client may want to differentiate these cases because it may only want to alert on the application-level internal error and not on the transient transport-level issue. (Indeed, this is the use case for which I'm envisioning using this change.)
Matching on a message is not as robust, however, as matching on an `h2::Error` and its reason code. (The message could change for example if a future version of Tonic decided to vary the message. This would break any users that matched on the previous version of the message.)
## Solution
Store the `h2::Error` used when creating a `tonic::Status` from a `h2::Error` and provide it as the `source` for purposes of `std::error::Error`. This will allow users to downcast it and match on the original `h2::Reason`.
At Embark we have a little helper function that converts a `&dyn
std::error::Error` into a `String` by walking the full chain of sources
(with `std::error::Error::source`) and joining them into a `String`.
We use that where we log errors to get as much information as possible
about whats causing an error. Works particularly well with anyhow's
`.context()` method.
However since `tonic::transport::Error` include its cause in their
`Display` impl we get the sources more than once.
As the cause can already be obtained through `std::error::Error::source`
no information should be lost by doing this.
Fixes https://github.com/hyperium/tonic/issues/632
As of `http-body` 0.4.1 its has had a `BoxBody` type similar to
`tonic::body::BoxBody`. It also has `Empty` and `Body::map_{data,err}`.
That means all the custom body things we had in tonic can basically be
replaced with that.
Note that this is a breaking change so we should merge this next time we
decide to ship a breaking release.
The breaking changes are:
- `tonic::body::Body` has been removed. I think its fine for users to
depend directly on `http-body` if they need this trait.
- `tonic::body::BoxBody` is now just a type alias for
`http_body::combinators::BoxBody<Bytes, Status>`. So the methods it
previously had are gone. The replacements are
- `tonic::body::Body::new` -> `http_body::Body::boxed`
- `tonic::body::Body::map_from` -> `http_body::Body::map_data` and
`http_body::Body::map_err` depending on which part you want to map.
- `tonic::body::Body::empty` -> `http_body::Empty`
Additionally a `Sync` bound has been added to a few methods. I actually
don't think this is a breaking change because the old
`tonic::body::Body` trait had `Sync` as a supertrait meaning the `Sync`
requirement was already there.
Fixes https://github.com/hyperium/tonic/issues/557
tonic-web enables tonic servers to handle requests from grpc-web
clients directly, without the need of an external proxy.
Co-authored-by: John Hernandez <[email protected]>
Co-authored-by: zancas <[email protected]>
Adds `tonic::Extensions` which is a newtype around `http::Extensions`.
Request extensions can be set by interceptors with
`Request::extensions_mut` and retrieved from RPCs with
`Request::extensions`. Extensions can also be set in tower middleware
and will be carried through to the RPC.
Since response extensions cannot be set by interceptors the main use
case is to set them in RPCs and retrieve them in tower middlewares.
Figured that might be useful.
Fixes https://github.com/hyperium/tonic/issues/255
