)]}'
{
  "commit": "88c3e68dfb2f1a3d5c2ada29b4eeef600c94c5ac",
  "tree": "523e5bf3121763d939b4263c1e80d9dafc1e0f3d",
  "parents": [
    "1a789c1daa48212dfa76704c102e182d8e5b7342"
  ],
  "author": {
    "name": "Michael Brown",
    "email": "mcb30@ipxe.org",
    "time": "Thu Dec 04 13:52:08 2025 +0000"
  },
  "committer": {
    "name": "Michael Brown",
    "email": "mcb30@ipxe.org",
    "time": "Thu Dec 04 14:47:45 2025 +0000"
  },
  "message": "[http] Abort connections after a long period of inactivity\n\nOnce an HTTP download has started (i.e. once all request headers have\nbeen sent), we generally have no more data to transmit.  If an HTTP\nconnection dies silently (e.g. due to a network failure, a NIC driver\nbug, or a server crash) then there is no mechanism that will currently\ndetect this situation by default.\n\nWe do send TCP keep-alives (to maintain state in intermediate routers\nand firewalls), but we do not attempt to elicit a response from the\nserver.  RFC 9293 explicitly states that the absence of a response to\na TCP keep-alive probe must not be interpreted as indicating a dead\nconnection, since TCP cannot guarantee reliable delivery of packets\nthat do not advance the sequence number.\n\nScripts may use the \"--timeout\" option to impose an overall time limit\non downloads, but this mechanism is off by default and requires\nadditional thought and configuration by the user (which goes against\niPXE\u0027s general philosophy of being as automatic as possible).\n\nAdd an idle connection watchdog timer which will cause the HTTP\ndownload to abort after 120 seconds of inactivity.  Activity is\ndefined as an I/O buffer being delivered to the HTTP transaction\u0027s\nupstream data transfer interface.\n\nDownloads over HTTPS may experience a substantial delay until the\nfirst recorded activity, since all TLS negotiation (including\ncross-chained certificate downloads and OCSP checks) must complete\nbefore any application data can be sent.  We choose to not reset the\nwatchdog timer during TLS negotiation, on the basis that 120 seconds\nis already an unreasonably long time for a TLS negotiation to take to\ncomplete.  If necessary, resetting the watchdog timer could be\naccomplished by having the TLS layer deliver zero-length I/O buffers\n(via xfer_seek()) to indicate forward progress being made.\n\nWhen using PeerDist content encoding, the downloaded content\ninformation is not passed through to the content-decoded interface and\nso will not be classed as activity.  Any activity in the individual\nPeerDist block downloads (either from peers or as range requests from\nthe origin server) will be classed as activity in the overall\ndownload, since individual block downloads do not buffer data but\ninstead pass it through directly via the PeerDist download\nmultiplexer.\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "f5416042a55c6793bc82c21fa0d08e916fc852e7",
      "old_mode": 33188,
      "old_path": "src/include/ipxe/http.h",
      "new_id": "fc3e7b7a1093eab590024cb9d77a7d2ec8a787b3",
      "new_mode": 33188,
      "new_path": "src/include/ipxe/http.h"
    },
    {
      "type": "modify",
      "old_id": "42512cda495242063e9a9ced506f5f3dff101f9c",
      "old_mode": 33188,
      "old_path": "src/net/tcp/httpcore.c",
      "new_id": "8fee0421ca30dfb765ce1def8323cbfac6ec22fa",
      "new_mode": 33188,
      "new_path": "src/net/tcp/httpcore.c"
    }
  ]
}