Summary
Curl test 1328 (HTTP GET a globbed range with -f) always hangs. When --fail is used with URL globbing and the first URL returns a 4xx error, urlx hangs instead of continuing to the next URL.
Expected behavior
urlx -f 'http://host/[13280000-13280001]' -o log/#1
- URL 1 (
/13280000) returns 404 → silently fail, continue to next URL
- URL 2 (
/13280001) returns 200 → output response body
- Process exits
Actual behavior
urlx hangs indefinitely after the first URL returns 404 with --fail.
Root cause
In crates/liburlx/src/protocol/http/h1.rs (~line 826), when --fail triggers on a 404:
fail_skip = true → body reading is skipped (no_body = true)
body_read_to_eof = false because the body was never read
can_reuse = keep_alive && !use_http10 && !server_wants_close && !body_read_to_eof → evaluates to true
The connection is returned to the pool with unread body data still on the socket (6 bytes: -nooo-). When the second URL reuses that pooled connection, the HTTP parser reads the stale body data instead of fresh response headers, corrupting the parse and causing a hang.
Suggested fix
In the can_reuse calculation (~line 826 of h1.rs), account for fail_skip:
let can_reuse = keep_alive
&& !use_http10
&& !server_wants_close
&& !body_read_to_eof
&& !(fail_skip && has_body_framing); // don't reuse if body was skipped but has framing
When fail_skip is true and the response has body framing (Content-Length or chunked), the connection must not be reused because the body wasn't drained.
Reproduction
./scripts/run-curl-tests.sh 1328 # always hangs
Summary
Curl test 1328 (
HTTP GET a globbed range with -f) always hangs. When--failis used with URL globbing and the first URL returns a 4xx error, urlx hangs instead of continuing to the next URL.Expected behavior
/13280000) returns 404 → silently fail, continue to next URL/13280001) returns 200 → output response bodyActual behavior
urlx hangs indefinitely after the first URL returns 404 with
--fail.Root cause
In
crates/liburlx/src/protocol/http/h1.rs(~line 826), when--failtriggers on a 404:fail_skip = true→ body reading is skipped (no_body = true)body_read_to_eof = falsebecause the body was never readcan_reuse = keep_alive && !use_http10 && !server_wants_close && !body_read_to_eof→ evaluates totrueThe connection is returned to the pool with unread body data still on the socket (6 bytes:
-nooo-). When the second URL reuses that pooled connection, the HTTP parser reads the stale body data instead of fresh response headers, corrupting the parse and causing a hang.Suggested fix
In the
can_reusecalculation (~line 826 ofh1.rs), account forfail_skip:When
fail_skipis true and the response has body framing (Content-Length or chunked), the connection must not be reused because the body wasn't drained.Reproduction
./scripts/run-curl-tests.sh 1328 # always hangs