Something instead of reqwest?

help
#1

I use reqwest for HTTP and have a bunch of problems with timeouts:

  • timeouts are per client, so I have to create new client, if some parts of REST API is slower then other
  • timeout can for HTTP request can be triggered before it even executed, if you execute several API requests: github issue
  • when I download big file via http, I need timeout per chunk,
    not per whole request, to prevent triggered timeout when user download 95% of big file

All this stuff is impossible with current reqwest,
and looks like reqwest development are stopped.

Any other good API clients, that are:

  • have good timeout handling
  • Rust only (except SSL part)
  • can use tokio under the hood
    ?
1 Like
#2

You can implement all timeout strategies if you use the async interface to reqwest combined with the tokio::time module. Additionally, reqwest is definitely not an abandoned project.

#3

I don't think so. Several requests can and use the same connection. So if you just wrap one request with fixed timeout you got problem, you need knowledge about all previous executed and not finished requests.

You can look at link that I provided, the issue was created in May 2020 and it doesn't even classified, I don't talk about some kind of reply in issue comment or fix from maintainers. So it looks like abandoned project for me.

#4

I know the main maintainer. Reqwest is not abandoned, even if there may be some issues that have not gotten attention. I have forwarded the question regarding control of connections in the connection pool. It's possible you have to drop down to hyper to do it.

The per-chunk timeout can definitely be done with tokio::time.

2 Likes
#5

The latest commit was 20 hours ago and there have been multiple commits per week for the past year. This is not what an abandoned project looks like.

1 Like
#6

Sean responds that if a connection is dropped before the full response is read, then the connection is killed and removed from the connection pool.

#7

Important thing to keep in mind that in Rust dropping of a future actively aborts it (runs its drop, which has to do cleanup). That's different than abandoning async operations in other languages (e.g. JS Promises and golang goroutines keep running even if nothing is waiting for them).

This means that externally-added timeouts are actually useful in Rust, and not everything needs to have internal handling of timeouts.

3 Likes