mirror of
https://github.com/ipxe/ipxe
synced 2025-12-06 17:30:26 +03:00
88c3e68dfb
Once an HTTP download has started (i.e. once all request headers have been sent), we generally have no more data to transmit. If an HTTP connection dies silently (e.g. due to a network failure, a NIC driver bug, or a server crash) then there is no mechanism that will currently detect this situation by default. We do send TCP keep-alives (to maintain state in intermediate routers and firewalls), but we do not attempt to elicit a response from the server. RFC 9293 explicitly states that the absence of a response to a TCP keep-alive probe must not be interpreted as indicating a dead connection, since TCP cannot guarantee reliable delivery of packets that do not advance the sequence number. Scripts may use the "--timeout" option to impose an overall time limit on downloads, but this mechanism is off by default and requires additional thought and configuration by the user (which goes against iPXE's general philosophy of being as automatic as possible). Add an idle connection watchdog timer which will cause the HTTP download to abort after 120 seconds of inactivity. Activity is defined as an I/O buffer being delivered to the HTTP transaction's upstream data transfer interface. Downloads over HTTPS may experience a substantial delay until the first recorded activity, since all TLS negotiation (including cross-chained certificate downloads and OCSP checks) must complete before any application data can be sent. We choose to not reset the watchdog timer during TLS negotiation, on the basis that 120 seconds is already an unreasonably long time for a TLS negotiation to take to complete. If necessary, resetting the watchdog timer could be accomplished by having the TLS layer deliver zero-length I/O buffers (via xfer_seek()) to indicate forward progress being made. When using PeerDist content encoding, the downloaded content information is not passed through to the content-decoded interface and so will not be classed as activity. Any activity in the individual PeerDist block downloads (either from peers or as range requests from the origin server) will be classed as activity in the overall download, since individual block downloads do not buffer data but instead pass it through directly via the PeerDist download multiplexer. Signed-off-by: Michael Brown <mcb30@ipxe.org>
iPXE README File Quick start guide: cd src make For any more detailed instructions, see http://ipxe.org