Problem
A request with a large body failed before reaching the server with:
httpx.LocalProtocolError: Cannot send 97519 bytes, flow control window is -49151
This surfaced through HTTPX. I'm filing it here because encode/httpx has issues disabled and HTTP/2 flow-control handling appears to live in httpcore.
Expected behavior
The client should handle HTTP/2 request-body flow control internally. If the available window is too small, httpcore should split the body, wait for WINDOW_UPDATE, or otherwise apply backpressure. Application code should not have to manually size or buffer request bodies to avoid violating the HTTP/2 flow-control window.
Actual behavior
httpcore appears to attempt to send a 97,519-byte chunk while the flow-control window is already negative, and the request fails with LocalProtocolError.
Why this looks like a bug
The caller is not managing HTTP/2 DATA frame sizes or connection-window accounting; httpcore is. A negative flow-control window leaking into a user-visible send error suggests the transport is trying to write before flow control permits it, instead of buffering, chunking, or waiting for window credit.
If the connection is already in an unrecoverable state, the error should ideally make that explicit. As written, this reads like a client-side flow-control handling failure for large request bodies.
Reproducer details
I do not yet have a minimal isolated script, but the failure mode is specific:
- HTTPX raised
httpx.LocalProtocolError
- message:
Cannot send 97519 bytes, flow control window is -49151
- trigger: sending a request with a large body over HTTP/2
I can add version numbers and a reduced repro once available.
Problem
A request with a large body failed before reaching the server with:
This surfaced through HTTPX. I'm filing it here because
encode/httpxhas issues disabled and HTTP/2 flow-control handling appears to live in httpcore.Expected behavior
The client should handle HTTP/2 request-body flow control internally. If the available window is too small, httpcore should split the body, wait for
WINDOW_UPDATE, or otherwise apply backpressure. Application code should not have to manually size or buffer request bodies to avoid violating the HTTP/2 flow-control window.Actual behavior
httpcore appears to attempt to send a 97,519-byte chunk while the flow-control window is already negative, and the request fails with
LocalProtocolError.Why this looks like a bug
The caller is not managing HTTP/2 DATA frame sizes or connection-window accounting; httpcore is. A negative flow-control window leaking into a user-visible send error suggests the transport is trying to write before flow control permits it, instead of buffering, chunking, or waiting for window credit.
If the connection is already in an unrecoverable state, the error should ideally make that explicit. As written, this reads like a client-side flow-control handling failure for large request bodies.
Reproducer details
I do not yet have a minimal isolated script, but the failure mode is specific:
httpx.LocalProtocolErrorCannot send 97519 bytes, flow control window is -49151I can add version numbers and a reduced repro once available.