Upgrade to hyper 1.x

[palant]

Search for duplicate feature request

• I already searched, and this feature request or improvement is not a duplicate.

Feature scope

Improve existing functionality

Feature request related to a problem

No response

Describe the solution you'd like

I’m trying to use this within another server solution, and the outdated libraries make it somewhat more complicated than necessary. Is there a reason to use hyper 0.14 rather than 1.2? If not, I may be able to create a pull request. The changes to Body and Server should be relevant here.

Describe alternatives you've considered

Obviously, hyper 0.14 is still supported. I merely have to juggle different versions of http::Request and such within the application.

Build target

All targets

Pull requests so far

• Replaced fork of the headers module by an in-tree handler for the Accept-Encoding header #354
• Do not mention request body type unnecessarily #340 #375
• Refactor graceful shutdown handling #377

[joseluisq]

The reason why we still rely on 0.14 (maintained) and we didn't start yet migrating is because there are dependencies used by SWS no ready for Hyper v1 like our fork of the headers crate and probably others too (to be confirmed).

Additionally, we do not still have an estimation of the effort necessary to migrate our modules. So if that could at least be known then we could have a better idea about the implications if any and plan the migration task(s).

But certainly, we know that migrate to Hyper v1 is something that we have to do at some point, so why not to get started with it

If you have ideas or want to help let us know.

[palant]

I see, I assumed this was merely a matter of finding the time. Unfortunately, I am no help at creating a migration plan – I don’t have any experience with hyper, so I can only figure things out by trying.

[palant]

like our fork of the headers crate

@joseluisq, what is the reason for this being a fork? It’s quite difficult to figure out the changes compared to upstream, with upstream changes being merged into it. However, it is my understanding that your fork is an improved version of hyperium/headers#70. And that pull request is merely adding new types, not changing any of the module internals. From the look of it, these types could also be added to a separate module like headers_ext while keeping the base headers module unchanged.

[palant]

I went through the dependencies. #354 should take care of the headers dependency, updating to 0.4 should be easy then. Other than that, http needs to be updated to 1.0 and http-serde to 2.1.0. That seems to be it, no other dependencies are tied to hyper from what I can tell.

[joseluisq]

@joseluisq, what is the reason for this being a fork? It’s quite difficult to figure out the changes compared to upstream, with upstream changes being merged into it. However, it is my understanding that your fork is an improved version of hyperium/headers#70. And that pull request is merely adding new types, not changing any of the module internals. From the look of it, these types could also be added to a separate module like headers_ext while keeping the base headers module unchanged.

@palant it was just our first attempt back in the day to support compression on demand via the Accept-Encoding header and the enum ContentCoding with lately other small additions like zstd support.

The idea of extracting the code and keeping it directly in SWS is also fine to me. That should be a step forward to help us to migrate to hyper v1.

[joseluisq]

I went through the dependencies. #354 should take care of the headers dependency, updating to 0.4 should be easy then. Other than that, http needs to be updated to 1.0 and http-serde to 2.1.0. That seems to be it, no other dependencies are tied to hyper from what I can tell.

Great! then I will check #354. We have to check if upgrading to http, http-serde, headers 0.4.0 and hyper required our code to be changed in some way.

Also, see if we need https://github.com/hyperium/hyper-util/tree/master, because as far as I know some utilities were moved to that crate.

[palant]

I’ve created a hyper-upgrade branch on my fork. For now I only changed dependencies and made some trivial adjustments, just to see what kind of errors come up. Most of the errors are unsurprisingly “unresolved import hyper::Body” – every piece of code working with bodies will have to be changed.

The rest of them are related to server setup, it changed drastically. There is the unsurprising “unresolved import hyper::server::Server” along with “unresolved imports hyper::server::conn::AddrIncoming, hyper::server::conn::AddrStream, hyper::service::make_service_fn” and finally “unresolved import hyper::server::accept”.

[palant]

Most of the time, generics can be used to avoid spelling out body types, see e642a2b. There are very few pieces of code actually working with response bodies and none working with request bodies. In fact, these generics can be used already and will make migration easier.