Date: Wed, 11 Feb 2026 20:12:21 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 293124] fetch fails to time out on https connection when bad length is sent by server w/connection reuse Message-ID: <bug-293124-227@https.bugs.freebsd.org/bugzilla/>
index | next in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=293124 Bug ID: 293124 Summary: fetch fails to time out on https connection when bad length is sent by server w/connection reuse Product: Base System Version: 14.3-STABLE Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: bin Assignee: bugs@FreeBSD.org Reporter: karl@denninger.net The following line SHOULD time out in 2 seconds if it cannot complete: $ fetch -T 2 -v -o /tmp/someurl.jpg https://some-target/something.jpg But in the specific case where the target mangles the return length (e.g. sets a zero content length in the headers and allows connection reuse, which is improper since the receiving end does not know when all the bytes have been sent) it hangs instead. This is such an example server and file (on a friend's machine) that boggled me for a good long while -- curl, incidentally, correctly receives this, but fetch hangs. And further, while it does EVENTUALLY time out, it is definitely NOT in the 2 seconds specified. In fact it hangs for nearly 90 seconds before terminating with a "transfer timed out." Note that TIMEOUT is defined in fetch.c as 120 (seconds) so absent an override it should time out in 2 minutes, but it in fact times out in a bit less than 90 seconds. The documentation SAYS: -T seconds, --timeout=seconds Set timeout value to seconds. Overrides the environment variables FTP_TIMEOUT for FTP transfers or HTTP_TIMEOUT for HTTP transfers if set. The capacity to specify a timeout appears to be broken. There is a comment that may be pertinent to this from January 22nd: commit fae1c84e95f7be4deacdab8a97f140714d8d2ae8 ....however a build WITH that patch in (from source) does NOT resolve it. FreeBSD 14.4-STABLE #29 stable/14-n273668-721dfa7e5a34-dirty: Wed Feb 11 13:59:28 EST 2026 I can provide a complete example URL that fails with this on a reproducible basis on request -- it is not on my system (it is on an associate's) or I'd include it in the bug report. [karl@NewFS ~]$ time fetch -T 2 -v -o /tmp/fetch.jpg https://photos....{elided}/_data/i/upload/2026/02/04/20260204231223-4f96b150-me.jpg resolving server address: photos.{elided}:443 SSL options: 82004850 Peer verification enabled Using OpenSSL default CA cert file and path Verify hostname TLSv1.3 connection established using TLS_AES_256_GCM_SHA384 Certificate subject: /CN=*.{elided} Certificate issuer: /C=US/O=Let's Encrypt/CN=E7 requesting https://photos.{elided}/_data/i/upload/2026/02/04/20260204231223-4f96b150-me.jpg fetch: transfer timed out fetch: /tmp/fetch.jpg appears to be truncated: 0/348401 bytes real 1m17.313s user 0m0.043s sys 0m0.000s [karl@NewFS ~]$ -- You are receiving this mail because: You are the assignee for the bug.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-293124-227>