feat: configure HTTP timeouts

CHANGELOG.md

@@ -2,6 +2,13 @@
 
 All notable changes to `locho` are documented here.
 
+## [Unreleased]
+
+- Adds an optional per-HTTP-service `upstream_timeout_secs` setting, defaulting
+  to 60 seconds and capped at 300 seconds.
+- Adds optional attachment-side HTTP response timeouts through
+  `http_timeout_secs` and `--http-timeout-secs`, defaulting to 60 seconds.
+
 ## [1.1.1] - 2026-08-06
 
 - Fixes release binaries reporting a dirty checkout when generated cargo-dist

FAQ.md

@@ -93,10 +93,17 @@ curl http://127.0.0.1:8765/path
 The host forwards requests to the explicitly configured HTTP upstream.
 
 Request and response bodies are streamed and limited to 32 MiB per body. The
-upstream request timeout is 30 seconds. WebSocket upgrades are not supported;
-use a TCP service when a non-HTTP protocol is required. HTTPS uses normal root
-validation by default. A private HTTPS upstream may specify an explicit PEM
-`ca_cert` in its service configuration.
+upstream request/response timeout defaults to 60 seconds and can be overridden
+per HTTP service with `upstream_timeout_secs` from 1 to 300 seconds. WebSocket
+upgrades are not supported; use a TCP service when a non-HTTP protocol is
+required. HTTPS uses normal root validation by default. A private HTTPS
+upstream may specify an explicit PEM `ca_cert` in its service configuration.
+
+The attachment can independently configure its response timeout with
+`http_timeout_secs` in `attachments.toml`, or `--http-timeout-secs` for a
+positional attach. It defaults to 60 seconds, applies while waiting for the
+response and between response-body chunks, and is separate from the host's
+upstream timeout.
 
 ## How are TCP services used?
 
@@ -123,8 +130,9 @@ configured endpoint.
 Ctrl-C stops accepting new local or remote connections and closes active tunnel
 connections. The process waits up to 10 seconds for active tasks to finish
 before forcing termination. Tunnel handshakes have a 10-second timeout, HTTP
-upstream request/response operations have a 30-second timeout, and TCP sessions
-have a 5-minute idle timeout.
+upstream request/response operations use the configured timeout, which defaults
+to 60 seconds, HTTP attachment response guards default to 60 seconds, and TCP
+sessions have a 5-minute idle timeout.
 
 ## Does locho create a VPN?
 

README.md

@@ -99,6 +99,9 @@ service has an independent attachment capability:
 name = "api"
 type = "http"
 upstream = "https://example.com"
+# Optional total upstream request/response timeout in seconds (1-300).
+# Defaults to 60 seconds.
+# upstream_timeout_secs = 90
 # Optional PEM CA certificate for a private HTTPS upstream.
 # ca_cert = "/path/to/upstream-ca.pem"
 
@@ -145,6 +148,10 @@ Attach one selected service locally using the command generated by `locho share`
 locho attach <host-id> api:http:<secret> --listen 127.0.0.1:8765
 ```
 
+For a one-off client-side HTTP response timeout, add
+`--http-timeout-secs <seconds>`. The value defaults to 60 seconds and accepts
+values from 1 to 300 seconds.
+
 For scripts that need only the token, use `locho secret`:
 
 ```sh
@@ -201,11 +208,14 @@ curl http://127.0.0.1:8765/path
 
 HTTP request and response bodies are streamed through the tunnel. Known-length
 bodies use length framing; chunked bodies use bounded chunk framing. Individual
-bodies are limited to 32 MiB, and HTTP requests have a 30-second upstream
-timeout. Hop-by-hop headers are not forwarded. WebSocket upgrades are not
-supported. HTTPS certificates are validated against the normal system roots by
-default; `ca_cert` may explicitly add a PEM CA certificate for a private
-upstream.
+bodies are limited to 32 MiB, and HTTP requests use a configurable upstream
+request/response timeout that defaults to 60 seconds and accepts values from 1
+to 300 seconds. Hop-by-hop headers are not forwarded. WebSocket upgrades are
+not supported. HTTPS certificates are validated against the normal system roots
+by default; `ca_cert` may explicitly add a PEM CA certificate for a private
+upstream. If an upstream fails after response headers have been forwarded, the
+attachment closes the response stream; an HTTP client may observe a truncated
+body rather than a replacement gateway status.
 
 A TCP service is attached to a local port and used by its native client:
 
@@ -280,6 +290,9 @@ listen_host = "127.0.0.1"           # optional; defaults to localhost
 [[services]]
 capability = "api:http:<secret>"
 listen_port = 8765
+# Optional attachment response timeout in seconds (1-300).
+# Defaults to 60 seconds.
+# http_timeout_secs = 90
 
 [[services]]
 capability = "database:tcp:<secret>"
@@ -301,8 +314,10 @@ are required.
 Host and attachment processes handle Ctrl-C gracefully: they stop accepting new
 connections, close active tunnel connections, and wait up to 10 seconds for
 active tasks to finish before terminating remaining tasks. Tunnel handshakes
-also have a 10-second timeout, and HTTP clients enforce a 30-second upstream
-request/response timeout.
+also have a 10-second timeout. HTTP hosts enforce the configured upstream
+request/response timeout, which defaults to 60 seconds. HTTP attachments enforce
+their configured response timeout, which also defaults to 60 seconds and applies
+between response chunks.
 
 Configuration is loaded and fully validated before the host starts. Service
 names are unique, limited to letters, numbers, `-`, and `_`, HTTP upstreams