Forward RERUM Pagination-* headers from /query

[thehabes]

Summary

Resolves #131.

RERUM rerum_server_nodejs#310 reports pagination on /query in four response headers.
TinyNode read only the body and built a fresh response, so the headers were dropped.
/query now copies any Pagination-Limit, Pagination-Skip, Pagination-Limit-Max, and Pagination-Skip-Max header RERUM returns onto its own response.
The copy happens before branching on resp.ok, so the headers survive on both the 200 and the 502.

A fixed list of names is used rather than a pagination- prefix scan, which keeps the canonical header casing and forwards only the documented contract.
Access-Control-Expose-Headers is already *, so no CORS change is needed.

What changed

File	Change
routes/query.js	Forward the four Pagination-* headers before the resp.ok branch
test/routes/query.test.js	Fetch mocks gain headers: new Headers(); new tests for forwarding on success, forwarding on error, absence, and no over-forwarding; the rejected-fetch test asserts no pagination headers

Verification

npm run allTests: 84 unit and 5 e2e tests pass, 0 failed, 0 skipped.

Against TinyNode running locally on a RERUM built from #310, body {"type":"Annotation"}:

Request	RERUM	TinyNode before	TinyNode after
no params	200, 100/0/500/100000	200, none	200, 10/0/500/100000
?limit=25&skip=5	200, 25/5/500/100000	200, none	200, 25/5/500/100000
?limit=1000	200, Pagination-Limit: 500	200, none	200, Pagination-Limit: 500
?skip=100001	400, both -Max	502, none	502, both -Max
?limit=1e3	400, both -Max	502, none	502, both -Max
/app/query?limit=1000	n/a	200, none	same as /query

TinyNode's default limit is 10, so no params reports Pagination-Limit: 10.

A cross-origin browser fetch from localhost:3001 to TinyNode on localhost:3002 read all four headers on the 200 and both -Max headers on the 502.

Out of scope

• TinyNode's own limit/skip check is looser than RERUM's new one. ?limit=1e3 and ?limit=0 pass TinyNode, RERUM rejects them, and the client gets a 502 (now with the -Max headers). ?limit=-1 is rejected by TinyNode before RERUM is called, so its 400 carries no pagination headers. Aligning the two is worth its own issue.
• The 502 body echoes the internal RERUM URL. This is existing behavior.

[cubap]

Review: works; consider deriving headers dynamically

The implementation correctly resolves #131: headers survive both the 200 and 502 paths, no headers are invented when RERUM doesn't send them, and the tests cover forwarding, absence, and over-forwarding. I like the explicit test that the rejected-fetch path adds no pagination headers.

One suggestion: the fixed PAGINATION_HEADERS list mirrors the upstream contract precisely, which protects canonical casing, but it also means TinyNode has to be updated if RERUM ever adds another pagination header. Could this route interpret the headers instead — for example, iterate
esp.headers and forward any whose name starts with Pagination-? That would keep TinyNode aligned with
erum_server_nodejs#310 without a code change when the header set grows. Totally understand if you prefer the explicit allow-list for predictability; if so, a brief code comment noting the dependency on #310 would help future maintainers.

Tiny note from reading est/routes/query.test.js: paginationHeaders is camelCase but tested against Express-lower-cased response keys. The variable name is slightly misleading; consider expectedHeaderKeysLower or similar.

Question on the deployment side: the upstream PR (#310) removes the RERUM_ prefix from MAX_QUERY_LIMIT / MAX_QUERY_SKIP. That changes the namespace for existing deployments. Is there a migration step or alias planned so that environments that already set RERUM_MAX_QUERY_* don't silently fall back to defaults?

[thehabes]

Review: works; consider deriving headers dynamically

The implementation correctly resolves #131: headers survive both the 200 and 502 paths, no headers are invented when RERUM doesn't send them, and the tests cover forwarding, absence, and over-forwarding. I like the explicit test that the rejected-fetch path adds no pagination headers.

One suggestion: the fixed PAGINATION_HEADERS list mirrors the upstream contract precisely, which protects canonical casing, but it also means TinyNode has to be updated if RERUM ever adds another pagination header. Could this route interpret the headers instead — for example, iterate esp.headers and forward any whose name starts with Pagination-? That would keep TinyNode aligned with erum_server_nodejs#310 without a code change when the header set grows. Totally understand if you prefer the explicit allow-list for predictability; if so, a brief code comment noting the dependency on #310 would help future maintainers.

Tiny note from reading est/routes/query.test.js: paginationHeaders is camelCase but tested against Express-lower-cased response keys. The variable name is slightly misleading; consider expectedHeaderKeysLower or similar.

Question on the deployment side: the upstream PR (#310) removes the RERUM_ prefix from MAX_QUERY_LIMIT / MAX_QUERY_SKIP. That changes the namespace for existing deployments. Is there a migration step or alias planned so that environments that already set RERUM_MAX_QUERY_* don't silently fall back to defaults?

Going to leave the PAGINATION_HEADERS technique as-is. We could just forward all headers, and I think at one point in time that is what we did. I'll make a new issue about forwarding RERUM headers.

Dev and Prod both have the correct .env settings. The code was the thing that had it wrong.