pmtiles-swarm 0.54.0 → 0.54.2

package/CHANGELOG.md

@@ -7,6 +7,34 @@
 ### 🐞 Bug fixes
 - _...Add new stuff here..._
 
+## 0.54.2
+### ✨ Features and improvements
+- **Written down and tested: a range read is cached exactly as a tile read is**, because it is the
+  same read. `serveArchiveFromSwarm` goes through the same acquisition, the same `TorrentSource` and
+  therefore the same piece cache, so `tiles.pieceCacheBytes`, `tiles.maxOpenArchives` and
+  `tiles.directoryCacheEntries` all bound it unchanged. The two doors warm each other: pulling the
+  header over HTTP leaves the tile endpoint warm for free, and a tile already read costs a range
+  request nothing. Five tests now hold that in place by counting what actually reaches the swarm —
+  including one that shrinks the byte budget to a single piece and watches the eviction happen.
+
+### 🐞 Bug fixes
+
+## 0.54.1
+### ✨ Features and improvements
+
+### 🐞 Bug fixes
+- **The public page offered a download of an archive the node did not hold.** With `publicDownload`
+  on, a cache-mode archive got a link labelled **download** that answers `409` — or, with
+  `serveArchiveFromSwarm` on, refuses a request carrying no `Range`, which reads as a broken node
+  rather than as a deliberate limit. `publicDownload` now needs the file to be here. `serveArchive`
+  is deliberately not conditioned that way, since a bounded range can be fetched from the swarm, and
+  neither setting is stored as `false` on this account — so both take effect on their own the moment
+  a download finishes.
+
+- **A range request with no `Range` header answered `411`.** That code is about a missing
+  `Content-Length` on the way in; the request here is well formed and it is the state of the resource
+  that makes it unanswerable, so it is now a `409` like the other "not here" refusals beside it.
+
 ## 0.54.0
 ### ✨ Features and improvements
 - **`serveArchiveFromSwarm` — a byte range for an archive this node does not hold.** Experimental,

package/docs/configuration.md

@@ -373,6 +373,17 @@ The response carries the same `ETag` and the same year-long `immutable` caching
 complete copy would give, because it is the same content: the infohash names
 those bytes wherever they were read from.
 
+**The pieces are cached exactly as a tile read caches them**, because it is the
+same read. A range goes through the same acquisition, the same `TorrentSource`
+and therefore the same piece cache, so `tiles.pieceCacheBytes`,
+`tiles.maxOpenArchives` and `tiles.directoryCacheEntries` all apply to it
+unchanged — and a node tuned for its memory stays tuned when this endpoint is
+used. It also means the two doors warm each other: somebody pulling the header
+over HTTP leaves the tile endpoint warm for free, and a tile already read costs
+a range request nothing. Underneath, in cache mode, the pieces land in
+[`cacheSavePath`](#cachesavepath) the same way, so what a reader asks for over
+HTTP hydrates the partial archive on disk just as a tile request does.
+
 **A node cannot be a web seed for an archive it does not hold**, whatever this is
 set to. [`selfWebSeed`](#selfwebseed) is refused on an incomplete archive and
 offered again when the download finishes — answering from the swarm and then
@@ -464,6 +475,15 @@ is off, whatever the file says. A web seed URL that answers `403` is worse than
 web seed, because a client spends its retries on it, and a download link that
 `403`s is worse than no link.
 
+**`publicDownload` also needs the file to actually be here.** A cache-mode
+archive is offered no download link, because there is nothing to download: the
+node holds none of it, and a link labelled "download" that answers `409` reads as
+a broken node rather than as a deliberate limit. `serveArchive` is deliberately
+_not_ conditioned that way — a bounded range can be fetched from the swarm, which
+is what [`serveArchiveFromSwarm`](#servearchivefromswarm) is for — and neither
+setting is stored as `false` on that account, so both take effect on their own the
+moment a download finishes.
+
 ### Per archive, per folder, per source
 
 The node's setting is the default. A [watched folder](#watched-folders), a

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "pmtiles-swarm",
-  "version": "0.54.0",
+  "version": "0.54.2",
   "description": "BitTorrent distribution for PMTiles map archives: create torrents, watch folders, publish and subscribe to RSS feeds, and seed through qBittorrent or an embedded client",
   "type": "module",
   "main": "src/index.js",

package/src/api.js

@@ -2382,7 +2382,11 @@ export function createApp({
     const asked = req.headers.range;
     if (!asked) {
       res.setHeader('accept-ranges', 'bytes');
-      return res.status(411).json({
+      // 409 rather than 411. The request is well formed -- 411 is about a
+      // missing Content-Length on the way in -- and what is wrong is the state
+      // of the thing being asked for: the whole file is not here, and fetching
+      // it through the swarm to stream back out is not an answer.
+      return res.status(409).json({
         error:
           'this node does not hold this archive, so it can only answer a ' +
           'byte range. Send a Range header.',

package/src/catalog.js

@@ -82,12 +82,26 @@ export function normalizeCategories(source) {
  */
 export function publishingFor(entry, config) {
   const serveArchive = entry?.serveArchive ?? config?.serveArchive ?? false;
+  // Whether the whole file is here. `serveArchive` does not depend on it —
+  // `serveArchiveFromSwarm` exists precisely so a node holding nothing can
+  // still answer a bounded range — but a download link does. A link labelled
+  // "download" on a public page has to hand over the file, and a cache-mode
+  // node cannot: it answers 409, or refuses a request with no Range, which
+  // reads as a broken node rather than as a deliberate limit.
+  //
+  // `selfWebSeed` is guarded separately, in setPublishing, because it has a
+  // lifecycle rather than a state: the URL is written into a .torrent and has
+  // to be added and withdrawn at the right moments, not merely reported as
+  // off. Resolving it to false here would withdraw a published seed the first
+  // time an archive was rechecked.
+  const held = entry?.complete !== false;
   return {
     serveArchive,
     selfWebSeed:
       serveArchive && (entry?.selfWebSeed ?? config?.selfWebSeed ?? false),
     publicDownload:
       serveArchive &&
+      held &&
       (entry?.publicDownload ?? config?.publicDownload ?? false),
   };
 }