Request client setting to allow RST instead of FIN on request cancelation.

[BlackRabbitCoder]

Problem

When a client request future is dropped/cancelled mid-send (e.g., partial body),
hyper-util sends FIN via poll_shutdown(). This tells the server "I'm done sending"
rather than "abort/discard."

Why RST would be better

• FIN + truncated body can cause server to wait for remaining data (timeout)
• Server might attempt to process incomplete request
• RST semantics ("abort") match the intent of cancellation

Current behavior

1. Request future dropped
2. Connection detects cancellation via poll_canceled()
3. poll_shutdown() called → FIN sent
4. Server receives incomplete request + graceful close

Suggested behavior

Option to send RST instead of FIN when a request is cancelled mid-flight.
Could be a pool config option like rst_on_cancel(true).

Workaround

Currently requires setting SO_LINGER=0 on the socket in a custom connector somehow just before connection is dropped.

[Souradip121]

Hi, I've been studying this issue and wanted to share my understanding before attempting a fix.

The core problem is that poll_shutdown() in dispatch.rs:156 sends a graceful FIN when a request is cancelled mid-body, but the correct semantic for cancellation is RST which is telling the server to discard the incomplete request entirely.

My current thinking on a fix:

Add an rst_on_cancel option to the client builder config
When a request future is dropped and poll_canceled() fires, check this flag
If set, set SO_LINGER=0 on the underlying socket before shutdown, which causes the OS to send RST instead of FIN
A few things I'm unsure about and would love guidance on:

Is there a clean way to reach the raw socket from within the connection teardown path, given hyper's I/O abstraction?
Should this be in hyper itself or hyper-util's client layer?
Is there a preferred pattern in this codebase for threading connector-level config down to the connection?
Happy to take a stab at this if the approach sounds reasonable which I just want to make sure I'm going in the right direction before writing code.

[seanmonstar]

I'm not so sure this is the right place to signal it. No HTTP server should be left waiting forever if the connectioned closed. It would understand that the message is incomplete. For example, if the server is hyper, it will understand.

[Catwoman08]

Closing as not actionable. We can always re-open if more information is added.