cloudwego/volo volo-http-0.2.0

Volo-HTTP 0.2.0

on GitHub

What's Changed

Features

Supports HTTP client

Volo-HTTP supports HTTP client now, you can use get function directly, or use ClientBuilder to build a client with some configurations.

Example is available at example-http-client.rs

Support HTTPS by rustls or native-tls

Volo-HTTP supports HTTPS by rustls or native-tls.

For simple applications, you can add one of rustls, native-tls or native-tls-vendored, and use volo::net::tls::ServerTlsConfig for server or volo::net::tls::TlsConnector for client directly without caring the difference between rustls or native-tls.

For advanced usage, you can use one or more features and build configs for rustls or native-tls and wrap them for use by your client or server.

Examples are available at http-tls-client.rs http-tls-server.rs.

Details

For more details, please refer:

• feat(volo-http): support http client by @wfly1998 in #350
• feat(volo-http): use generic types for resp and err by @wfly1998 in #361
• feat(volo-http): record uri and method in server stats by @wfly1998 in #366
• feat(volo-http): support request with any body by @wfly1998 in #369
• feat(volo-http): support disabling stats by @wfly1998 in #370
• feat(volo-http): support config for server and client by @wfly1998 in #372
• feat(volo-http): remove connection info, add ext for parts by @wfly1998 in #379
• feat(volo-http): support https by @wfly1998 in #385
• feat(volo-http): support default target for client by @wfly1998 in #403
• feat(volo-http): support load balance on client-side by @wfly1998 in #408
• feat(volo-http): support setting query and form for client by @wfly1998 in #409
• feat(volo-http): support path extractor by @wfly1998 in #413

Break Changes

Move server related module path

For support Client, most server related modules are moved into mod server. For example,

• volo_http::route -> volo_http::server::route
• volo_http::into_response -> volo_http::server::into_response

Introduce features client and server

Considering that most users only use one of client or server, we do not provide all of them by default.

We provide features client, server, default_client, default_server. The client and server have basic functions only, the default_s are including functions with serde.

For upgrading from 0.1.x to 0.2.0, you should add the feature default_server.

Remove State

At the beginning of designing the server, we referred to some designs of axum, including State. But we found State to be very intrusive, which means we need to adapt it everywhere. And the State can be replaced by many things, e.g., lazy_static or LazyCell. So we removed it.

Considering that we have not exposed the with_state interface before, all break changes are removing the generic type S and the argument state: S for all impl FromContext and impl FromRequest.

In short:

• impl<S> FromContext<S> for YourTypes -> impl FromContext for YourTypes
• impl<S> FromRequest<S> for YourTypes -> impl FromRequest for YourTypes

Use http::request::Parts

In the previous design, we saved anything to ServerContext (or HttpContext in older versions) from request including method, uri, headers and peer address. But we found it is not a good design, so keep it in Parts and only save context related data in the ServerContext, e.g., the peer address.

So methods in FromContext and FromRequest should be updated like this (considering removing State):

• fn from_context(cx: &mut ServerContext, state: &S) -> fn from_context(cx: &mut ServerContext, parts: &mut Parts)
• fn from_request(cx: &mut ServerContext, body: BodyIncoming, state: &S) -> fn from_request(cx: &mut ServerContext, parts: Parts, body: BodyIncoming)

Remove ConnectionInfo

We referred actix-web and introduced ConnectionInfo, but we found that it has many hard-coded logic when processing Forwarded and X-Forwarded-.... We want to provide a more flexible interface, so we removed it and introduced trait RequestPartsExt for Parts including function forwarded for parse the header Forwarded to a struct Forwarded.

Although this is not a convenient way, but it is flexible enough. For adapting the change, you should process the Forwarded and X-Forwarded-... by yourself.

Remove too many re-exported types

Re-exporting too many types from other crates is not a simple and elegant design, so we removed most of them. You should import Method, Uri, HeaderMap from http (or volo_http::http), and import Incoming from hyper (or volo_http::hyper::body::Incoming).

Others

• chore(volo-http): refactor context and service for server by @wfly1998 in #354
• chore(volo-http): separate client & server, split features by @wfly1998 in #362
• chore(volo-http): only make Route<Infallible> as Service by @wfly1998 in #368
• chore(volo-http): support Body::from_body with any error by @wfly1998 in #371
• fix(volo-http): fix misspelled type and variable by @wfly1998 in #386
• chore(volo-http): refactor config of context by @wfly1998 in #387
• chore(volo-http): refactor client error by @wfly1998 in #395
• chore(volo-http): adjust stats of client and server by @wfly1998 in #396
• chore(volo-http): use elegant way for creating method router by @wfly1998 in #410
• chore(volo-http): refactor server and remove common stats by @wfly1998 in #411
• chore(volo-http): add docs for important modules by @wfly1998 in #414

Full Changelog: volo-http-0.1.18...volo-http-0.2.0