An ergonomic, batteries-included HTTP Client for Rust

optional features, so your Cargo


An ergonomic, batteries-included HTTP Client for Rust.

  • Plain bodies, JSON, urlencoded, multipart
  • Customizable redirect policy
  • HTTP Proxies
  • HTTPS via system-native TLS (or optionally, rustls)
  • Cookie Store
  • WASM
  • Changelog


This asynchronous example uses Tokio and enables some optional features, so your Cargo.toml could look like this:

And then the code:

Blocking Client

There is an optional "blocking" client API that can be enabled:


On Linux:

  • OpenSSL 1.0.1, 1.0.2, 1.1.0, or 1.1.1 with headers (see

On Windows and macOS:

  • Nothing.

Reqwest uses rust-native-tls, which will use the operating system TLS framework if available, meaning Windows and macOS. On Linux, it will use OpenSSL 1.1.


Licensed under either of


Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.


Collection of the latest Issues



Comment Icon1

Often when building urls I find myself joining multiple things to a base Url. It would be very convenient to have some way to pass multiple strings to Url.join at once, instead of having to chain and handle errors for multiple calls in a row

Perhaps this could be done by implementing a version that accepts a vector of strings? Or if performance is a concern maybe a macro would work?



Comment Icon0

The entire boilerplate to build an efficient proxy cycling mechanism for applications such as web scraping and others is always a very tedious one and there aren't many good solutions out there for easy integration with reqwest.

It would be a great addition, in my opinion, to include a built-in option for providing a collection of proxies and a small infrastructure for automatic management that cycles through them, drops after unsuccessful attempts, and maximizes the cycling of proxies.

Something resembling a proxy management system is already implemented in reqwest but it instead attempts to reuse the same one until it becomes "bad". I propose a small addition to this by allowing the option to instead cycle through them trying to maximize the usage of different proxies in each request instead of trying to use the same one. This is very useful in situations where we may want to create many connections using different proxies each time. Alongside this, other features such as blacklisting proxies with X number of failed attempts and other "easy but cumbersome-to-implement" strategies for basic proxy management could be implemented.

I don't think I have enough experience with rust but I offer myself to help with whatever I can.

Do you guys think this idea would fit the philosophy of your library?



Comment Icon3

Take this production code:

When a part called foo is passed in the form, this code will work properly. However, when a file with path foo/bar is passed in, the part with said nested form fails.

If the form part name does not contain any slashes, it will work properly.

EDIT: This issue seems to be also discussed in #419 #1218 #467



Comment Icon1

Could it be possible to set an option/flag for reqwest to out-of-the-box use/cycle through random user-agents? If needed, the function could take an array of possible user-agents.



Comment Icon0

I have an app where I'm spawning futures that take a Client as an argument and perform multiple operations and then returns the Client back. Each client is using a different proxy and upon return of the future, I'd like to know which proxy it was used, however the attributes are private. How would I go about this?

As a side note, I'm building new clients for every connection as each conn needs a new proxy. Is there a cheaper way to do this, by changing proxies without having to build a new client?




Comment Icon0

reqwest's ClientBuilder set tcp_nodelay to true by default, but hyper's HttpConnector set it to false.

So if I set ClientBulder's tcp_nodelay to true, reqwest should pass this setting to hyper's HttpConnector. But I can't find where this code is.

I think maybe this commit cause the above problem.

If self.nodelay is true, the program has no chance to call http.set_nodelay

I haven't read all the relevant code, so please ignore this issue if tcp_nodelay is updated in other ways.



Comment Icon0

Hi, I stumbled upon this issue merely by code inspection (i.e. I didn't test it). I saw that the get_from_environment function at does the following:

Unless I'm missing something, here we're ignoring http_proxy in CGI mode too; if this is intentional, I'd at least expect a comment indicating so (and perhaps an improvement to the warning text).

If this is confirmed to be a bug, I'd be happy to send a patch to fix it. Thanks.



Comment Icon1

The h3 crate is mostly working, and while the hyper 1.0 roadmap has changes need to allow new HTTP versions which don't use TcpStream to be added, it would be helpful to try out the h3 crate before it appears in hyper. To that end, I believe adding "experimental" (or "unstable") support to reqwest is a great way to just that.

Overall, I'd guesstimate this is a medium-sized issue. Even if familiar with how hyper and reqwest usually work, I'd imagine it would take a few hours to pipe everything through. A few more if you're not familiar.

Here's a (potentially incomplete) list of what would need to be done:

  • Add an optional git dependency on h3-quinn (s2n-quic-h3 could also be used).
  • Edit reqwest's async_impl::client::Client to hold both a hyper::Client but also a small pool of HTTP/3 connections.
  • In Client::request, if the version is HTTP_3, then use the h3 pool.
    • The DNS resolver would need to be cloned for the h3 pool.
    • The TLS config would also need to be cloned.
    • It may help to look at the h3 client example.
    • If a connection doesn't exist for the target authority, resolve the address, create a UdpSocket, and pass it to quinn.
    • Once ready, spawn the h3::client::Driver into Tokio.
    • Use the SendRequest to start sending a request.
  • Adjust the async_impl::response::Response and Body to be an enum of the regular repr, and another variant for the h3 types. Or boxed them if it's easy to do so.


Comment Icon1

I'm trying to POST to an external http server which uses a self signed certificate. I have put this certificate in a PEM file that I read using Certificate::from_pem and pass to Client::builder(). This worked on macOS using native TLS, but after I switched to rustls-tls I need to also call (on both macOS and Linux):

Why is this? I don't want to accept invalid certificates, just trust the provided server certificate. (There is no chain of certificates, just one)

The error I get is:

source: hyper::Error(Connect, Custom { kind: Other, error: Custom { kind: InvalidData, error: InvalidCertificateData("invalid peer certificate: UnknownIssuer") } })



Comment Icon2

It would be nice to change certain things per request which are currently set on the Client. For some settings the Client acts as a way to set default settings. My use case would be setting a different client certificate depending on the hostname. One can work around this by using multiple Clients but it would be nice to keep the connection pooling and other advantages of sharing a Client between requests. Setting default_headers already works this way.

I'm not sure if this is worth the trouble. Maybe reqwest users should just keep a Client per hostname (for example) if they want different connection settings per hostname.

Also see #353.



Comment Icon0


I like reqwest quite a lot, however there is often one significant pain point for me: If I read the response body (e.g. via json or text), the Response is consumed.

I've read why Response is implemented as it is, and I'm wondering if there is anything that can be done to improve the situation.

In end-user code, it is possible to work around this limitation (but I feel, it is still painful).

However, when designing an HTTP client that wraps reqwest, it seems my options are all suboptimal. Basically, this design choice influences my API design significantly.

Currently, I see the following options:

  1. I can use Response::chunk to read the body, without invalidating the Response. In this case, I have to reimplement what text, json, etc. does. text uses an unsafe block, so then my crate can't use #![forbid(unsafe_code)] (I believe. I've never actually used any unsafe code, so far. Which is another reason, why I'd like to avoid it, but performance is important to me).

  2. I can mem::take and clone the data I need from the Response, which for my wrapper crate, is everything. This adds some unnecessary allocation to my client, and adds a lot of additional code (I believe. Basically, I'd have to duplicate most of the API of Response).

As far as I understand the situation, Request anyway doesn't protect users completely from misuse. Or what happens, if I read the response body via chunk and then call text? To me, it seems, that is exactly what Response tries to prevent, but it seems easily doable (and there doesn't seem to be a note of what will happen, if text or similar is called afterwards).

I thought about, what could be done, and I came up with following possible solutions:

  1. Providing methods that can be used to take all needed values, without additional allocations. But how would that look for cookies without allocating? Url probably also can't be replaced without allocating (but I'm not sure). And this would mean, duplicating a lot of Responses code (in my case).

  2. Adding a way to provide text to variants of text and json that don't consume the Response (i.e. text_from_string). Then we could use chunk to get the body, and then call text_from_string to get the same behavior that text has.

  3. Just adding variants that don't consume the Resonse. This shouldn't be any different from the already existing chunk method.

  4. Adding variants of text and json that consume the Response and return a type that has all the data and methods of Response, but without the methods that read the body. Something like:

I think, (4) is by far the best end-result. Ideally, there would be something similar that allows streaming the body (e.g. ResponseWithBody<String> and ResponseWithBody<Stream>).

(2) also would be okay, but wouldn't prevent misuses as (4) does (which basically prevents any misuse, especially, if chunk could be deprecated/removed from Response). On the other hand, in this case (3) would have the same trade-offs, and maybe would be easier to add.

Does anybody have any thoughts on this?



Comment Icon1

I'm facing an issue when using the reqwest::multipart part of this library. I'm currently attempting to make a POST request to a website that only accepts Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryXXXXXXXXXXXX.

Reqwest's current support for multipart data automatically derives the boundary and such using a standard that does not comply with what WebkitFormBoundary desires.

Current multipart boundary generation:

The request I'm attempting to emulate:

Is there any alternative for sending multipart forms, or to manually construct them?



Comment Icon1

The Issue

reqwest does not offer enough flexibility, and therefore must be configured for edge cases.

An example is TLS renegotiation in non-controllable environments, such as Xbox Live API (see for more details).

native-tls seems to work fine for Linux, however MacOS has renegotiation disabled by default on security framework for security reasons. rusttls does not support renegotiation due to security reasons.

The solution

The workaround I have found is to use hyper-openssl with hyper directly. However, this does not provide the user-friendliness that reqwest does. Seeing how reqwest uses hyper under the hood, I believe there should be an option for the user to configure a predefined hyper client.



Comment Icon3

It would be nice to see an example how to download in parallel with reqwest.

Like hypothetically lets say I have 100 URLs and I want to download in parallel such that I never have more than 5 downloads going at a time. It would be nice to see an example with that kind of complexity.



Comment Icon1

There doesn't seem to be a way to specify a maximum amount of time to wait for data. This means that after a network change (on macOS, not sure about other operating systems), a request will wait for the normal timeout before aborting. It should be able to see that no more data is coming in and use a different timeout in this case.



Comment Icon0

This is kinda coming from, and probably/mainly also a request for hyper; I want to be able to limit the amount of requests that reqwest is making, concurrently, per host/IP.

The reasons for this is similar as in #386; too many requests are made at once, but unlike that issue, this is on a large process scale, where adding a semaphore to limit requests from all over the client would increase complexity a bit.

However, coming from python, this seemed like a "solved problem" for me; limit the amount of connections per host to a sane amount (10, or 20). Chrome does this as well (6 per host, with advantages gained by using HTTP2), however, it seems that reqwest and hyper do not limit themselves.

Even if opt-in, I'd like for there to be an option to limit the amount of pooled connections per host, to make hitting that "too many open files" error impossible.



Comment Icon2

I am building a service that needs to fetch user-provided URLs. I have added some protection such that the user can't request localhost, whatever.internal or However I have not found a way to block a request such as internal.some-real-domain.example which resolves to an internal IP address. I think it would be valuable if reqwest could provide an internal hook, much like the redirect hook that could validate (and maybe rewrite) IP addresses before connections are made.

The following cases should be handled:

  1. Top level requests to IP addresses.
  2. Top level requests to domains.
  3. Redirects to either of the above.

A possible API would be something like this:

(This is modeled after the redirect module but maybe the naming could be tweaked to be more clear in this case.)

For my use I would do something like this:

Unanswered questions:

  • Async?
  • How to handle non-IP connections. For example UNIX sockets or Tor addresses. I think maybe the IP policy can be skipped for these as they are both knowable based on the URL (a hostname can't resolve to either of these AFAIK).
  • This always resolves the IP. Maybe it could be made lazy to make this essentially a full DNS resolution hook, but then we are back to "async?"


  • The user can manually resolve the hostname then pass the IP to reqwest along with Host: header and SSL verification configuration. This is difficult and error prone.
  • A general DNS resolution hook can be added. This may be a bit more flexible but would make it harder to support things like SRV records (or whatever alternative is currently being proposed).
  • Do nothing. Then users of reqwest are at risk of information leaks if they connect to user-provided URLs.


Comment Icon1

Is your feature request related to a problem? Please describe. I'm trying to build a tracing backend that ships logs via HTTPS requests. I want to disable logging for this tracing backend because allowing logging would cause a positive feedback loop where logs cause more logs to be produced indefinitely.

I can disable logging for the thread that reqwest's future is on. Unfortunately, hyper, the backend for this crate, also tokio::spawns some futures, for which I cannot directly control logging. hyper has some way of controlling the spawning of new tasks, and I can use that to disable logging in background threads as well:

(Note that NoSubscriber of tracing currently has a bug:, so you need a copy of its source code to actually stop tracing from logging.)

Describe the solution you'd like Possible solutions:

  1. Expose setting the hyper::rt::Executor directly on reqwest::ClientBuilder.
  2. Create some wrapper trait so you don't expose hyper's trait directly.
  3. Add a setting no_logging on reqwest::ClientBuilder that stops hyper's spawned tasks from logging.


Comment Icon0

It would be nice to have way to check if it is dns error:

In other words to have method Error::is_dns. To separate other network connect errors from this specific failure.



Comment Icon1

the reqwest report errors when add the following headers:

the code to test:


How to add http headers prefix ":" showed above? thanks a lot!



Comment Icon1

I love the optional json() feature, my HTTP code looks super tidy:

but I imagine I'm going to be streaming lots of data out this request. The code json(&T) looks like it's forcing all the data to be buffered first:

specifically serde_json::to_vec(json). Could this be converted to use serde_json::to_writer()? Maybe this is a async/blocking code problem? Looks like that's the case in serde's world:

Just wanted to kick off a conversation here and have something searchable.


Find the latest versions by id

v0.11.11 - Jun 13, 2022

What's Changed

  • Add HTTP/2 keep-alive configuration methods on ClientBuilder.
  • Add ClientBuilder::http1_allow_obsolete_multiline_headers_in_responses().
  • Add impl Service<Request> for Client and &'_ Client.
  • (wasm) Add RequestBuilder::basic_auth().
  • Fix RequestBuilder::header to not override sensitive if user explicitly set on a HeaderValue.
  • Fix rustls parsing of elliptic curve private keys.
  • Fix Proxy URL parsing of some invalid targets.

New Contributors

v0.11.10 - Mar 14, 2022

What's Changed

  • Add Error::url() to access the URL of an error.
  • Add Response::extensions() to access the http::Extensions of a response.
  • Fix rustls-native-certs to log an error instead of panicking when loading an invalid system certificate.
  • Fix passing Basic Authorization header to proxies.

New Contributors

v0.11.9 - Jan 10, 2022

  • Add ClientBuilder::http09_responses(bool) option to allow receiving HTTP/0.9 responses.
  • Fix HTTP/2 to retry requests interrupted by an HTTP/2 graceful shutdown.
  • Fix proxy loading from environment variables to ignore empty values.

New Contributors

v0.11.8 - Jan 10, 2022

  • Update internal webpki-roots dependency.

New Contributors

v0.11.7 - Nov 30, 2021

  • Add blocking::ClientBuilder::resolve() option, matching the async builder.
  • Implement From<tokio::fs::File> for Body.
  • Fix blocking request-scoped timeout applying to bodies as well.
  • (wasm) Fix request bodies using multipart vs formdata.
  • Update internal rustls to 0.20.

New Contributors ❤️

v0.11.6 - Nov 02, 2021

  • Several WASM request body fixes.

New Contributors

v0.11.5 - Oct 07, 2021

  • Add ClientBuilder::http1_only() method.
  • Add tls::Version type, and ClientBuilder::min_tls_version() and ClientBuilder::max_tls_version() methods.
  • Implement TryFrom<Request> for http::Request.
  • Implement Clone for Identity.
  • Fix NO_PROXYenvironment variable parsing to more closely match curl's. Comma-separated entries are now trimmed for whitespace, and * is allowed to match everything.
  • Fix redirection to respect https_only option.
  • (wasm) Add Body::as_bytes() method.
  • (wasm) Fix sometimes wrong conversation of bytes into a JsValue.
  • (wasm) Avoid dependency on serde-serialize feature.

New Contributors 😍

v0.11.4 - Jun 21, 2021

  • Add ClientBuilder::resolve() option to override DNS resolution for specific domains.
  • Add native-tls-alpn Cargo feature to use ALPN with the native-tls backend.
  • Add ClientBuilder::deflate() option and deflate Cargo feature to support decoding response bodies using deflate.
  • Add RequestBuilder::version() to allow setting the HTTP version of a request.
  • Fix allowing "invalid" certificates with the rustls-tls backend, when the server uses TLS v1.2 or v1.3.
  • (wasm) Add try_clone to Request and RequestBuilder

v0.11.3 - Apr 12, 2021

  • Add impl From<hyper::Body> for reqwest::Body.
  • (wasm) Add credentials mode methods to RequestBuilder.

v0.11.2 - Mar 09, 2021

  • Add CookieStore trait to customize the type that stores and retrieves cookies for a session.
  • Add cookie::Jar as a default CookieStore, easing creating some session cookies before creating the Client.
  • Add ClientBuilder::http2_adaptive_window() option to configure an adaptive HTTP2 flow control behavior.
  • Add ClientBuilder::http2_max_frame_size() option to adjust the maximum HTTP2 frame size that can be received.
  • Implement IntoUrl for String, making it more convenient to create requests with format!.

v0.11.1 - Feb 18, 2021

  • Add ClientBuilder::tls_built_in_root_certs() option to disable built-in root certificates.
  • Fix rustls-tls glue to more often support ALPN to upgrade to HTTP/2.
  • Fix proxy parsing to assume http:// if no scheme is found.
  • Fix connection pool idle reaping by enabling hyper's runtime feature.
  • (wasm) Add Request::new() constructor.

v0.11.0 - Jan 05, 2021

  • Change multipart to be an optional cargo feature.
  • Remove deprecated methods.
  • Update to Tokio v1.0.
  • Update to Bytes v1.0.
  • Update to hyper v0.14.

v0.10.10 - Jan 05, 2021

  • Add tcp_keepalive option to blocking::ClientBuilder.
  • Add multipart::Part::stream_with_length constructor, to create a streaming part with a known length.
  • Add ClientBuilder::https_only option, to allow requiring URLs to be https.
  • Change default tcp_keepalive value to be disabled.

v0.10.9 - Nov 20, 2020

  • Add rustls-tls-native-roots, rustls-tls-webpki-roots, and rustls-tls-manual-roots Cargo features, to configure which certificate roots to use with rustls.
  • Add ClientBuilder::tcp_keepalive() method to enable TCP keepalive.
  • Add ClientBuilder::http1_writev() method to force enable or disable vectored writes.
  • Add Error::is_connect() method to identify if the error is related to connection-establishment.
  • Add blocking::ClientBuilder::brotli() method.
  • Windows: Update default protocol to HTTP for HTTPS system proxies, when a protocol is not specified.
  • (wasm) Add support for Cloudflare workers runtime.
  • (wasm) Add ClientBuilder::default_headers() method.
  • (wasm) Add RequestBuilder::build() method.

v0.10.8 - Aug 25, 2020

  • Add must_use to RequestBuilder and ClientBuilder.
  • Fix Windows system proxy detection of Fiddler proxies.
  • (wasm) Add headers method to RequestBuilder.
  • (wasm) Add execute method to Client.
  • (wasm) Add TryFrom<http::Request> for Request.
  • (wasm) Fix checking for global window to work in non-browser environments.
  • (wasm) Fix sending of an empty body when not required.

v0.10.7 - Jul 24, 2020

  • Add NO_PROXY environment variable support.
  • Add more Error::{is_request, is_body, is_decode} getters.
  • Add conversion of reqwest::ClientBuilder to reqwest::blocking::ClientBuilder.
  • Add headers_mut() to reqwest::blocking::Response.
  • (wasm) Add form(), query(), multipart and bearer_auth() to RequestBuilder.

v0.10.6 - May 29, 2020

  • Changed handling of URLs that don't have http: or https: schemes, returning an error instead.
  • Fixed a potential hyper-rustls feature conflict.

v0.10.5 - May 28, 2020

  • Add ClientBuilder::pool_idle_timeout option.
  • Add ClientBuilder::pool_max_idle_per_host option, deprecate max_idle_per_host.
  • Add Response::content_length for WASM target.
  • Enable TCP_NODELAY by default.
  • Implement TryFrom<http::Request> for blocking::Request.
  • Implement TryFrom<http::Request> for Request.
    • Removes From<http::Request> for Request.
    • This is technically a breaking change, but was a mistake. It was not valid to convert from an http::Request to a reqwest::Request in an infallible fashion. It would panic if the conversion was not possible. Instead, the implementation has been changed to TryFrom to indicate it could fail.

v0.10.4 - Mar 04, 2020

  • Add trust-dns optional feature to change DNS resolver.
  • Add bytes() method to reqwest::blocking::Response.
  • Add buffer() method to reqwest::blocking::Body.
  • Implement From<http::Request> for reqwest::Request.

v0.10.2 - Feb 21, 2020

  • Add Brotli support, enabled with the optional brotli feature. ✨
  • Add Client::use_preconfigured_tls(tls_connector) allowing manual configuration of TLS options.
  • Implement Default for blocking Client, ClientBuilder, and multipart::Form.
  • (wasm) Add Response::error_for_status() method.
  • (wasm) Add Response::json() method.
  • (wasm) Implement Default for Client and ClientBuilder.

v0.10.1 - Jan 09, 2020

  • Add socks optional feature to support SOCKS5 proxies.
  • Add RequestBuilder::timeout() to configure a timeout for a single request, instead of using the client's timeout.
  • Add ClientBuilder::connection_verbose() option to enable verbose IO logs.
  • (wasm) Add RequestBuilder::fetch_mode_no_cors() option.
  • (wasm) Add Response::url() getter method.

v0.10.0 - Dec 30, 2019


  • Add std::future::Future support.

  • Add wasm32-unknown-unknown support (with fewer features).

  • Add ability to pass async Response as the body of another Request.

  • Add Body::as_bytes() method.

  • Add Response::bytes_stream() method to get body as an impl Stream.

  • Add Request::try_clone() method.

  • Change default Client API to async. The previous blocking client API is avaialble at reqwest::blocking.

  • Change to no longer send a default User-Agent header. Add one via ClientBuilder::user_agent().

  • Change to enable system/environment proxy detection by default.

  • Change default-tls feature to only include ClientBuilder options that both native-tls and rustls support.

  • Change default feature set to reduce unnecessary dependencies. Most features are disabled by default:

    • blocking: The reqwest::blocking (synchronous) client API.
    • cookies: Cookie store support.
    • gzip: Automatic response body decompression.
    • json: Request and response JSON body methods.
    • stream: futures::Stream support.
  • Change Error internal design, removing several Error::is_* inspector methods.

  • Change Redirect API:

    • Renamed types to be part of the redirect module (for example, reqwest::RedirectPolicy is now reqwest::redirect::Policy).
    • Removed loop_detected and too_many_redirect methods from redirect::Attempt, replaced with a generic error method.
    • The default policy no longer specifically looks for redirect loops (but they should be caught by the maximum limit).
  • Fix checking HTTP_PROXY environment variable if it the environment is from a CGI script.

  • Fix removal of username/password of parsed proxy URL.

  • Update url to v2.0.

  • Update hyper to v0.13.

  • Update http to v0.2.

v0.10.0-alpha.2 - Nov 12, 2019

  • Add Request::try_clone() method.
  • Add HTTP2 window size configuration to ClientBuilder.
  • Add Body::as_bytes() method.
  • Add Response::bytes() method for WASM target.
  • Add RequestBuilder::body() method for WASM target.
  • Change to enable system/environment proxy detection by default.
  • Fix checking HTTP_PROXY environment variable if it the environment is from a CGI script.
  • Fix removal of username/password of parsed proxy URL.
  • Fix pinning async-compression dependency to last alpha.

v0.10.0-alpha.1 - Oct 08, 2019

  • Add std::future::Future support.
  • Add wasm32-unknown-unknown support (with fewer features).
  • Add ability to pass async Response as the body of another Request.
  • Change default Client API to async. The previous blocking client API is avaialble at reqwest::blocking.
  • Change default feature set to reduce unnecessary dependencies. Most features are disabled by default:
    • blocking: The reqwest::blocking (synchronous) client API.
    • cookies: Cookie store support.
    • gzip: Automatic response body decompression.
    • json: Request and response JSON body methods.
  • Change futures::Stream support to a disabled-by-default unstable-stream feature.
  • Change Error internal design, removing several Error::is_* inspector methods.
  • Update url to v2.0.

v0.9.21 - Oct 08, 2019

  • Add executor method to ClientBuilder.
  • Send User-Agent header in CONNECT requests to proxies.

v0.9.20 - Oct 08, 2019

  • Improve error message when proxy connections fail to tunnel.
  • Update mime_guess and rustls dependencies.

v0.9.19 - Jul 19, 2019

  • Add ClientBuilder::use_sys_proxy() to enable automatic detect of HTTP proxies configured on the system.
  • Add ClientBuilder::no_proxy() to disable system proxies. This is the default for 0.9, but will change to detecting system proxies by default in 0.10.
  • Add support for streaming request bodies in the async client.
  • Add async::Response::text() that returns a Future of the full body decoded to a String.
  • Add Clone for Certificate.

v0.9.18 - Jul 19, 2019

  • Fix Cookie headers to no longer send as percent-encoded (instead, exactly as sent by the server).

v0.9.17 - Jul 19, 2019

  • Fix Cookie headers so as to not include attributes from the Set-Cookie (like HttpOnly, Secure, etc).

v0.9.16 - Jul 19, 2019

  • Add Response::text_with_charset() to allow setting the default charset to decode.
  • Add Error::source() implementation.
  • Add async::ClientBuilder::timeout() option, will timeout the connect, request, and response body futures.
  • Fix gzip + chunked transfer encoding issue preventing connection reuse.
  • Fix RequestBuilder::query() to not add just "?" if the encoded query is empty.
  • Fix including new cookie headers when response is a redirect.

Information - Updated Jul 26, 2022

Stars: 5.9K
Forks: 676
Issues: 286

When you need to pretend you are a REST API, but you're really not

Facade is a Rust-based HTTP transformation layer to seamlessly convert REST calls into GraphQL calls for piecemeal API migrations

When you need to pretend you are a REST API, but you're really not

Rust helpers for serving HTTP GET and HEAD responses with

This crate supplies two ways to respond to HTTP GET and HEAD requests:

Rust helpers for serving HTTP GET and HEAD responses with

When you need to pretend you are a REST API, but you're really not

Vostok is a Rust-Based HTTP Transformation Layer To Seamlessly Convert REST Calls Into GraphQL Calls For Piecemeal API Migrations

When you need to pretend you are a REST API, but you're really not

Eve-rs is a middleware-based rust http framework which is inspired from ExpressJS framework

Let's create a demo application using eve-rs, using an intuative approach to get a better understanding of the framework

Eve-rs is a middleware-based rust http framework which is inspired from ExpressJS framework


HTTP mocking for Rust!

Before upgrading, make sure to check out the rustfmt as a general code style

HTTP mocking for Rust!

Rust Urbit HTTP API

This library wraps the Urbit ship http interface exposing it as an easy-to-use Rust crate

Rust Urbit HTTP API

HTTP Server with Rust

Rust http server from scratch

HTTP Server with Rust

ehttp: a minimal Rust HTTP client for both native and WASM

If you want to do HTTP requests and are targetting both native and web (WASM), then this is the crate for you!

ehttp: a minimal Rust HTTP client for both native and WASM

Here lies my attempt to create a multi thread webserver based off of Rust and...

Here lies my attempt to create a multi thread webserver based off of Rust and using HTTP and TCP networking protocols :)

Here lies my attempt to create a multi thread webserver based off of Rust and...


Multithread HTTP Server developed with Rust

Facebook Instagram Twitter GitHub Dribbble