-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Hyper 1.0 support #1325
Comments
I guess the newer FromRequestParts and IntoResponseParts functions and State help Cover the loss of tower::Service. But this will heavily affect every single layer-based library when and if you do update to the newest Hyper. So maybe we can improve and prepare all the Parts changes to make migration easier later. I am willing to switch my libraries over to using them so they can be used as Examples for other library makers to change theirs over too. I'm guess hyper-util will be a faster change with more API breaking branch? I think Axum should also have its own Body type. This would make it easier to Abstract the Body from different source's and allow you more flexibility over them. |
I've started the work in #1882 but it's currently blocked by tower-http getting updated. That is blocked by figuring out how to implement the (de?)compression middleware. |
An update on where we're at with regards to hyper 1.0 support:
Finally most of the high level utilities that were previously in hyper (such as |
This was fixed in #1882. See https://github.com/tokio-rs/axum/milestone/6 for things left to do before axum 0.7 can be shipped. |
Hyper is aiming to ship 1.0 this year and in the process making a lot of changes to the public API which will impact axum. We can discuss the changes here.
Off the top of my head the biggest changes will probably be
tower::Service
support since tower-service wont be 1.0 in time.hyper::Server
into hyper-util. I don't think we should have a public dependency on hyper-util since breaking releases would cascade into axum.hyper::Body
(or possibly moving it into hyper-util). I think we should consider giving axum-core its own body type. Relevant to Middleware that change the request body have poor usability #1110I haven't thought much about this yet but once 0.6.0 is out we start that work.
Relevant links
The text was updated successfully, but these errors were encountered: