[COLOR=var(--gl-text-color-subtle)]
The WebIf accept loop inherits a 600s SO_RCVTIMEO from[/COLOR]setTCPTimeouts(), which is designed for long-lived reader
connections. For HTTP request handling this is far too generous:
a stalled or dead client can hold a WebIf thread for up to
10 minutes per connection.
Introduce setWebifTCPTimeouts() and call it after setTCPTimeouts()
in http_server(). This overrides three socket options for every
accepted WebIf connection:
SO_RCVTIMEO = 10s bound stalled blocking reads
SO_SNDTIMEO = 10s bound stalled blocking writes
TCP_USER_TIMEOUT = 10s bound unacknowledged TCP data where supported
This keeps the tightened timeouts local to HTTP handling and avoids
changing behavior for readers or other long-lived protocol
connections.
Limitations:
- SO_RCVTIMEO is a per-read idle timeout, not a wall-clock request
deadline. A client trickling data byte-by-byte resets the timer on
every successful read() and can extend the connection indefinitely.
Closing that requires a total request deadline in readRequest().
- For HTTPS, the SSL handshake retry loop uses poll() with an
infinite timeout. SO_RCVTIMEO has no effect there; a client can
still pin a WebIf worker during the handshake phase regardless of
this change.
[COLOR=var(--gl-text-color-subtle)]
Co-authored-by: [/COLOR][COLOR=var(--gl-text-color-subtle)]
tem_invictus <[email protected]>[/COLOR]