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`.
