fix(relay): bound HTTP request reads

[andrei-21]

Enable Hyper's HTTP/1 header timeout and enforce a hard deadline
on request bodies so stalled clients cannot retain file descriptors.

Restrict the server to HTTP/1 because protocol auto-detection occurs
before Hyper's header timeout.

[SeverinAlexB]

Downgrading to HTTP/1 only is quite bad. Did you research if there are not alternatives?

[andrei-21]

Downgrading to HTTP/1 only is quite bad. Did you research if there are not alternatives?

Alternatives are:

• support HTTP/2 in relay and properly defend from the issue, but it requires a custom acceptor, see the commit
• support only HTTP/1 but enable HTTP/2 on nginx and forward it as HTTP/1
• move from axum to Salvo, but it is a totally different framework

[86667]

This is a lot of complex code just for timeouts.

Whats wrong with a simple hard deadline per-connection using existing exposed config options in hyper? Do we expect for there to be requests which take more than 30s to return? If so, could we just set the deadline to 60s instead, surely that is high enough for all requests which are going to be returned to return. Especially considering the payloads are tiny.

I need convincing here that the complexity justifies the gain of allowing users of pkarr to indefinitely wait for dht responses.

[andrei-21]

Whats wrong with a simple hard deadline per-connection using existing exposed config options in hyper?

Nothing inherently. A hard per-connection deadline is simpler, but Hyper has no direct option for it.

Its downside is that expiry kills valid in-flight requests and all multiplexed HTTP/2 streams. A sufficiently long deadline may be acceptable, but it differs from the current logic, which times out only while waiting for a request and lets active requests finish.

[andrei-21]

@86667 cb0acc7 commit implements a smarter version of your idea.
The commit implements a fixed maximum connection lifetime. Once reached, the server gracefully stops accepting new requests, allows in-flight requests up to 30 seconds to finish, then forcibly closes the connection. It also adds initial-header timeouts, connection limits, and HTTP/1–HTTP/2 resource bounds.

[SeverinAlexB]

Aren't we going the wrong direction with this PR? Instead of Hyper managing the timeout, shouldn't we either

• timeout the pkarr call with tokio::time::timeout.
• Fix pkarr so it actually always returns within the given set timeout (preferred).

This feels like fighting symptoms instead of addressing the root cause. Other app working with pkarr will have the same issues.

[andrei-21]

Aren't we going the wrong direction with this PR? Instead of Hyper managing the timeout, shouldn't we either

* timeout the pkarr call with `tokio::time::timeout`.

* Fix pkarr so it actually always returns within the given set timeout (preferred).

This feels like fighting symptoms instead of addressing the root cause. Other app working with pkarr will have the same issues.

The failure reproduced here happens before pkarr is called. Opening 200 TCP connections and sending no HTTP data retained 200 file descriptors indefinitely. The request never reaches Axum, the relay handler, or the DHT client, so a timeout around the pkarr call cannot address it.
This PR therefore gives the HTTP transport its own resource bounds: incomplete-header deadlines, request-body deadlines, connection/stream limits, and bounded connection lifetime. These are separate from the application-level DHT timeout and remain necessary even if pkarr always honors its timeout.

[SeverinAlexB]

I am confused. Are you saying every hyper http server is bugged and easy to DDOS?

[andrei-21]

I am confused. Are you saying every hyper http server is bugged and easy to DDOS?

Yes and no. Axum intentionally focuses on HTTP-level routing and handling, while protections such as connection, request, and body timeouts often span multiple layers and must be configured separately.