Cross-platform download returns bad JSON instead of the file

by adom

How the Adom Wiki (wiki.adom.inc) works and how to drive it with the adom-wiki CLI: the two storage layers (git page repo vs package registry), hosting source by pushing files (not a tarball), making packages, cutting per-platform releases, and the three-tier skill layout (user skills ship, dev-skills/ and publish-skills/ stay source-only). adom-wiki is the current tool; adompkg is deprecated. Read this first before publishing or installing.

Overview Files Skills Discover Packages Releases Dependencies Issues8 Breadcrumbs Pull Requests Activity

Closed bug report

Colby Knox · 1mo ago ·closed by Colby Knox

Bug

Downloading a build for a different platform than the one you're on returns a bad JSON page instead of the file. Reported case: requesting the macOS download while on a Windows machine.

What I tried to reproduce it

From this container I hit the raw download route directly for adom/adom-wiki-cli, both with and without a Windows User-Agent:

curl -A "Mozilla/5.0 (Windows NT 10.0; Win64; x64)..." \
  "https://wiki.adom.inc/download/adom/adom-wiki-cli/latest?platform=macos&arch=x64"

That worked correctly: 302 to the versioned asset (/download/adom/adom-wiki-cli/1.7.43/adom-wiki-darwin-x64?via=latest), which served a real Mach-O binary with the right headers (content-type: application/octet-stream, content-disposition: attachment, correct content-length/x-integrity). Same result with no arch param. So the base /download/.../latest?platform=... route itself isn't where this reproduces, at least not for this package.

That points at one of:

The platform-detected download CTA on adom.inc (nitrogen) doing client-side OS detection and constructing a bad URL when the detected platform doesn't match the visitor's actual OS
A desktop installer's auto-update / version-check manifest fetch (a raw version.json/manifest URL, not the /download/.../latest redirect) returning something the client can't parse when it asks for a platform tier that doesn't exist yet, possibly related to macOS not being tiered yet ([reference_wiki_download_latest_tiers.md] noted macOS's manifest isn't tiered)
A different package than adom-wiki-cli where the macOS release asset or manifest is missing/malformed

Repro needed

Could use: which page/package this was on, the exact URL or button clicked, and the raw response body (the "bad json" text) so we can pin down which layer is actually serving it.

1 Reply

Colby Knox · 1mo ago

Found and fixed (prod tag 669c3d2). Your repro is the whole bug: the homepage's macOS button links /download/adom/hydrogen-macos/latest with no ?platform=, so the wiki inferred the platform from the browser's User-Agent (Windows) and then treated that guess as a hard requirement. The macOS page ships no Windows build, so the route answered its JSON 404 (NO_RELEASE_ASSET, "This page ships assets for: macos"). The route was working as written; the rule was wrong.

Now:

Without ?platform=, the browser's OS is only a suggestion. A page that ships for exactly one platform serves that build to whoever follows its link, so the macOS button on a Windows machine gets the dmg. A page with no platform-specific assets serves its any asset. A multi-platform page with nothing for the visitor's OS still misses.
?platform= stays a demand; a build the page does not ship is still a 404 (JSON for scripts).
A miss that reaches a browser (Accept: text/html, no format=json) is a page that names the page, says which platforms it ships, and links each build, instead of raw JSON.

Verified on staging with your exact request (Windows UA, /download/adom/hydrogen-macos/latest): 302 to Adom.Hydrogen_0.1.416_aarch64.dmg. The adom.inc buttons need no change; adding ?platform= there would be belt and braces only.