Introduced in #1563, the HTTP Upgrade/CONNECT API currently is accessed via hyper::Body::on_upgrade. This has some downsides that I'd like to address with a modified API:
- It makes the
Body type fatter.
- It requires people keep the
Body around, meaning they can't use stream combinators to read the body first, and then wait for the upgrade to finish. This also makes it more annoying for users who may wish adjust their http::Request<Body> into some http::Request<Doodad>.
Proposed API
Similar to the proposal in #1586, the change would be to pass the http::Request or http::Response to a free function.
hyper::upgrade::on(req_or_resp) -> OnUpgrade
- We can also allow passing just a mutable reference, thus not consuming the request or response.
- Optional other functions could be added, but not necessary:
has_upgrade, etc.
Implementation Plan
The types would be inserted into the http::Extensions of the request/response (though with a private wrapper type to hide the exact details).
- Add the new
hyper::upgrade::on function.
- The
Body::on_upgrade method would become #[deprecated].
- So as to not be a behavioral breaking change, the
OnUpgrade would need to be placed in both the Body and the Extensions, wrapped in some Arc<Lock> that only allows taking it once.
I'd like to in a future release be able to not put it in an Arc<Lock> and place it in the Body, but I'm not sure how that could really be done in 0.13.x. (I knew I'd find something I forgot to change after finally releasing XD).
Introduced in #1563, the HTTP Upgrade/
CONNECTAPI currently is accessed viahyper::Body::on_upgrade. This has some downsides that I'd like to address with a modified API:Bodytype fatter.Bodyaround, meaning they can't use stream combinators to read the body first, and then wait for the upgrade to finish. This also makes it more annoying for users who may wish adjust theirhttp::Request<Body>into somehttp::Request<Doodad>.Proposed API
Similar to the proposal in #1586, the change would be to pass the
http::Requestorhttp::Responseto a free function.hyper::upgrade::on(req_or_resp) -> OnUpgradehas_upgrade, etc.Implementation Plan
The types would be inserted into the
http::Extensionsof the request/response (though with a private wrapper type to hide the exact details).hyper::upgrade::onfunction.Body::on_upgrademethod would become#[deprecated].OnUpgradewould need to be placed in both theBodyand theExtensions, wrapped in someArc<Lock>that only allows taking it once.I'd like to in a future release be able to not put it in an
Arc<Lock>and place it in theBody, but I'm not sure how that could really be done in 0.13.x. (I knew I'd find something I forgot to change after finally releasing XD).