Consider a better error abstraction for the Handler trait #3
Comments
reem
added a commit
to reem/hyper
that referenced
this issue
Sep 7, 2014
…) pairs. This allows downstream users to have total control of their concurrency strategy, while also exposing a very nice, streaming interface for frameworks to build on. This also resolves issues surrounding the use of IoResult as the return type of Handler::handle, because handlers now have complete control over how to handle internal failure. Fixes hyperium#3 Fixes hyperium#4
dicej
added a commit
to dicej/hyper
that referenced
this issue
Dec 18, 2024
This is a prototype intended to spur discussion about what support for 1xx informational responses should look like in a Hyper server. The good news is that it works great (for HTTP/1 only, so far). The bad news is it's kind of ugly. Here's what I did: - Add `ext::InformationalSender`, a type which wraps a `futures_channel::mspc::Sender<Response<()>>`. This may be added as an extension to an inbound `Request` by the Hyper server, and the application and/or middleware may use it to send one or more informational responses before sending the real one. - Add code to `proto::h1::dispatch` and friends to add such an extension to each inbound request and then poll the `Receiver` end along with the future representing the final response. If the app never sends any informational responses, then everything proceeds as normal. Otherwise, we send those responses as they become available until the final response is ready. TODO hyperium#1: Also support informational responses in the HTTP/2 server. TODO hyperium#2: Come up with a less hacky API? TODO hyperium#3: Add test coverage. Signed-off-by: Joel Dice <joel.dice@fermyon.com>
dicej
added a commit
to dicej/hyper
that referenced
this issue
Dec 18, 2024
This is a prototype intended to spur discussion about what support for 1xx informational responses should look like in a Hyper server. The good news is that it works great (for HTTP/1 only, so far). The bad news is it's kind of ugly. Here's what I did: - Add `ext::InformationalSender`, a type which wraps a `futures_channel::mspc::Sender<Response<()>>`. This may be added as an extension to an inbound `Request` by the Hyper server, and the application and/or middleware may use it to send one or more informational responses before sending the real one. - Add code to `proto::h1::dispatch` and friends to add such an extension to each inbound request and then poll the `Receiver` end along with the future representing the final response. If the app never sends any informational responses, then everything proceeds as normal. Otherwise, we send those responses as they become available until the final response is ready. TODO hyperium#1: Also support informational responses in the HTTP/2 server. TODO hyperium#2: Come up with a less hacky API? TODO hyperium#3: Add test coverage. Signed-off-by: Joel Dice <joel.dice@fermyon.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
IoResult is generally pretty limiting, and this just encourages tons of "OtherIoError" instead of building meaningful abstractions. I am biased to recommend https://github.com/reem/rust-error.git
EDIT: Upon further thought, I think that such a complex error abstraction might be inappropriate, what you really want is
Result<(), Box<Show>>because all you are doing is showing the type. This also allows downstream users maximum flexibility. You will, unfortunately, have to write a small hack to get around the lack ofimpl Show for Box<Show>.The text was updated successfully, but these errors were encountered: