Skip to content

docs: document cancel safety for client send_request futures#4070

Open
lihan3238 wants to merge 1 commit into
hyperium:masterfrom
lihan3238:docs-4054-cancel-safety
Open

docs: document cancel safety for client send_request futures#4070
lihan3238 wants to merge 1 commit into
hyperium:masterfrom
lihan3238:docs-4054-cancel-safety

Conversation

@lihan3238
Copy link
Copy Markdown
Contributor

Summary

Refs #4054. Documents hyper's cancellation behavior on the two client send_request futures, plus a small crate-level pointer.

Per seanmonstar's suggestion in the issue:

...would it be better to have a small section on the relevant futures about cancellation? Or maybe in combination with a small mention at the crate level, "futures are cancel safe, see individual features for behavior when canceled"

This PR does both.

Changes

src/client/conn/http1.rs — adds # Cancel safety to SendRequest::send_request:

Dropping the returned future is the supported way to cancel an in-flight HTTP/1 request. Because HTTP/1 has no in-protocol way to abort a single request without affecting the shared connection, hyper closes the underlying connection when a request future is dropped before completion. Any subsequent calls on the same SendRequest will return a canceled error.

src/client/conn/http2.rs — adds # Cancel safety to SendRequest::send_request:

Dropping the returned future is the supported way to cancel an in-flight HTTP/2 request. The stream is reset with RST_STREAM (CANCEL error code); the shared connection remains usable for other in-flight and future requests. The peer is notified immediately rather than continuing to send a response body that would be discarded.

src/lib.rs — brief crate-level mention pointing at the per-future docs.

Notes

  • Plain code spans (no intra-doc links) in the crate-level note to avoid broken-link warnings when cargo doc runs without --features client.
  • Issue author (@jorendorff) said they'd "look into this when I have a chance" 12 days ago — happy to defer or merge this as a starting point. The wording follows the technical content they already laid out in the issue body.
  • Scope limited to the client-side cancellation paths the issue author was confident about; server-side behavior left for a follow-up since the issue author noted they hadn't verified it.

Per discussion in hyperium#4054: hyper futures are cancel safe via drop.
Document the protocol-specific behavior on cancellation:

- HTTP/1: dropping closes the underlying connection (no in-protocol
  per-request abort)
- HTTP/2: dropping resets the stream with RST_STREAM (CANCEL); shared
  connection stays usable for other in-flight and future requests

Also adds a brief crate-level Cancel safety section pointing readers
at the per-future docs, per seanmonstar suggestion in the issue.

Refs hyperium#4054
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant