+77
−3
+9
−0
test/test_http_range_streaming.cpp
0 → 100644
+240
−0
Loading
RequestEvent's Range-GET branch sent headers-only (send(..., -1)) for
every protocol and relied on ResponseEvent being invoked again later
via EPOLLOUT re-arm to stream the body. For H1, reattachConnection()
only re-arms EPOLLOUT if something is still queued at that exact
moment -- a headers-only send leaves nothing queued, so that re-arm
never fires and the connection hangs forever having already promised
a real Content-Length.
Every <video> element requests with Range: by default, so this fires
on ordinary video playback. Each hang permanently parks one of
proxyplus's H1 dispatch worker threads; enough concurrent video
requests exhausts the whole (small, fixed) pool, at which point every
request through the proxy -- Range or not -- queues behind it forever,
wedging the entire site.
Fix: for H1 (whose dispatch already runs on its own dedicated
per-connection thread, not a shared epoll worker), relay the whole
body synchronously right here instead of deferring. H2/H3 keep the
deferred approach since _resumeH2Streams / the H3 stream pool
self-drive further ResponseEvent calls independent of epoll re-arming.
New test_http_range_streaming pins down the HttpClient streaming
contract this depends on. 8/8 tests passing.
Co-Authored-By:
Claude Sonnet 5 <noreply@anthropic.com>