Currently, both cargo deny and our MSRV checks use Cargo.lock file which has unified features and versions across both the axum crates and all the examples. This can hide some issues as usually when someone adds an example, they might use cargo add which will silently update the dependency for the whole repository. Some compilation errors (like axum requiring [email protected] while it uses features from [email protected]) will then be hidden.
I don't think most users would ever need to use the minimal versions anyway so this is not as severe, but someone might run into compilation errors.
It's possible for an HTTP request to get stuck (due to network issues or
malicious clients) halfway through the request line or header, in which
case no amount of timeouts configured by an application using axum/tower
will help, since Hyper hasn't yet handed off the request to the service.
This has two consequences:
- Wasted memory: Up to ~1 MB per connection in the worst case, compared
to the ~2.5 kB used by a regular idle connection.
- A `with_graceful_shutdown` signal will cause the server to stop
accepting new requests, but then hang instead of actually stopping.
This changes axum::serve to configure a Timer for HTTP/1 connections,
which activates Hyper's default timeout (currently 30 seconds).
The timeout applies only to the request line and request header, not the
request body or subsequent response (where axum applications can instead
simply configure a timeout using `tower_http::timeout::TimeoutLayer`).
The timeout does not currently apply to newly opened connections, even
though Hyper's `header_read_timeout` SHOULD apply here too since 1.4.0;
discussion on tokio-rs#2741 suggests a possible TokioIo issue. However, the
graceful shutdown still works as expected for such connections.
The timer is only enabled for HTTP/1 here since similar functionality
does not currently appear to exist for HTTP/2 connections in Hyper.
This is a breaking change for any axum::serve users who currently rely
on being able to begin sending a HTTP/1 request, and then take more than
30 seconds to finish the request line and headers, or rely on keeping
connections idle for 30+ seconds between requests.
David Mládek