Update check: say what the forge answered, not zlib's "incorrect header check" #34

2026-09-29T14:54:52-04:00

michael commented

2026-09-29 14:54:52 -04:00

Why

On 29 Sept both booths' admin pages said the repo could not be reached: "incorrect header check". That is zlib failing to unpack what it was handed. What it was handed was Gitea's login page: the site-wide "require sign-in to view" setting had been switched on, and a Gitea that wants a sign-in does not refuse the branch archive — it redirects the download to /user/login, which arrives as a 200 of HTML. The updater followed the redirect and tried to gunzip a web page. Nothing in the message said so.

What

fetchArchive() now tells the truth about what came back, before zlib sees it:

redirected to a login page → http://10.3.8.90:3000 requires a sign-in to read michael/ProdDash@main — turn off "require sign-in to view" in Gitea, or make the repo readable without one
any other non-gzip answer (a captive portal, a wrong forge address) → … answered with a web page instead of the michael/ProdDash@main archive — check the forge address and that the repo is readable without a sign-in, or the content type when it is not HTML
an HTTP error still reads HTTP 404 fetching michael/ProdDash@main.

Shell 1.10.2 (brought up to date with main after 1.10.0 and 1.10.1 landed). No behaviour change on a healthy forge.

Verified

tools/update-check.test.js (new): starts a mock forge whose archive answer switches at runtime and a real server.js pointed at it, then reads the shell status the admin page shows — the login redirect names the sign-in and the Gitea setting and never says "header check"; a bare HTML answer says "a web page instead of the … archive"; a 404 says so; a real tar.gz parses, reads version 9.9.9 and offers the update; and a broken forge afterwards does not pass off the last good read as current. tools/unbundled.test.js and tools/layout-roundtrip.test.js pass on the merged branch.

The Gitea setting itself was turned off on 29 Sept; both booths check the repo again.

🤖 Generated with Claude Code

## Why On 29 Sept both booths' admin pages said the repo could not be reached: **"incorrect header check"**. That is zlib failing to unpack what it was handed. What it was handed was Gitea's login page: the site-wide "require sign-in to view" setting had been switched on, and a Gitea that wants a sign-in does not refuse the branch archive — it redirects the download to `/user/login`, which arrives as a 200 of HTML. The updater followed the redirect and tried to gunzip a web page. Nothing in the message said so. ## What `fetchArchive()` now tells the truth about what came back, before zlib sees it: - **redirected to a login page** → `http://10.3.8.90:3000 requires a sign-in to read michael/ProdDash@main — turn off "require sign-in to view" in Gitea, or make the repo readable without one` - **any other non-gzip answer** (a captive portal, a wrong forge address) → `… answered with a web page instead of the michael/ProdDash@main archive — check the forge address and that the repo is readable without a sign-in`, or the content type when it is not HTML - an HTTP error still reads `HTTP 404 fetching michael/ProdDash@main`. Shell **1.10.2** (brought up to date with main after 1.10.0 and 1.10.1 landed). No behaviour change on a healthy forge. ## Verified `tools/update-check.test.js` (new): starts a mock forge whose archive answer switches at runtime and a real `server.js` pointed at it, then reads the shell status the admin page shows — the login redirect names the sign-in and the Gitea setting and never says "header check"; a bare HTML answer says "a web page instead of the … archive"; a 404 says so; a real `tar.gz` parses, reads version 9.9.9 and offers the update; and a broken forge afterwards does not pass off the last good read as current. `tools/unbundled.test.js` and `tools/layout-roundtrip.test.js` pass on the merged branch. The Gitea setting itself was turned off on 29 Sept; both booths check the repo again. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

michael added 1 commit 2026-09-29 14:54:58 -04:00

Update check: say what the forge answered, not zlib's "incorrect header check" 601dc9e8b0

A Gitea that requires a sign-in does not refuse the branch archive: it
redirects the download to its login page, which arrives as a 200 of HTML,
and the admin page then reported zlib failing to unpack it — "incorrect
header check". Both booths showed exactly that on 29 Sept once the sign-in
requirement was switched on.

The updater now names the case: "… requires a sign-in to read
michael/ProdDash@main — turn off 'require sign-in to view' in Gitea, or
make the repo readable without one". Any other answer that is not a gzip
archive says what came back instead — a web page, or the content type —
and where to look.

tools/update-check.test.js drives the check against a mock forge: the login
redirect, a bare HTML answer, an HTTP error, and a real archive that must
still parse and be offered.

Shell 1.9.3.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

michael referenced this pull request

2026-09-30 14:07:24 -04:00

Shell 1.10.1: header menus open where their button is, folded bar or not; ProdCom 1.3.3 keeps its filter on a narrow tile #39

michael added 1 commit 2026-09-30 14:22:35 -04:00

Merge remote-tracking branch 'origin/main' into claude/update-error-message 409f2c258e