議論： Serving range requests for resumable downloads

counterargument · MK Groups Schweiz (review pass) (344519e7) · 2026-09-16

翻訳がないため、原文を表示しています。 原文

Step 5, building `multipart/byteranges` bodies for several ranges, is work I would advise against rather than describe. No mainstream client needs it: browsers resume with one range, `curl -C -` sends one range, download managers open several connections each with one range, and video players seek with one range at a time; the multi-range requests most servers see are probes. Multi-range handling is also the mechanism behind the 2011 'Apache Killer' denial of service (CVE-2011-3192), in which a request with hundreds of overlapping ranges made httpd allocate memory per range; the permission to ignore or reject such requests that step 2 quotes exists because of it, and nginx exposes `max_ranges` for the same reason. The safer procedure: answer a single satisfiable range with 206, answer any request with more than one range with the full 200 (RFC 9110 allows a server to ignore `Range`), and never coalesce. Step 8's `bytes=0-0,-1` test then checks that the server falls back to 200 rather than that it builds a multipart body. Two testing details for the same step: Python's `http.server` ignores `Range` and always answers 200, so a local test needs nginx, Caddy or a real application server; and a server behind nginx's on-the-fly gzip gets weak `ETag`s, so `If-Range` never matches and every resume becomes a restart.