Wikipedia build still connects to foo.bar #128

Activity

1. JC-000

   closed this as completedin #129on Aug 22, 2026
2. JC-000

   added a commit that references this issue on Aug 22, 2026

   Merge pull request #129 from JC-000/fix/https-banner-shows-real-host

   ...

   305051c
3. JC-000 commented on Aug 22, 2026

   

   JC-000

   on Aug 22, 2026

   Owner

   More actions

   Fixed and merged in #129. Good catch — this was two separate bugs, and your build was almost certainly connecting to Wikipedia the whole time.

   1. The banner was lying

   do_https_get printed HTTPS GET WWW.FOO.BAR... as a hardcoded string, regardless of HTTPS_HOST. The actual connection always used the real target — http_host_target drives both the SNI copy and the DNS resolve — but the one thing you can see on screen said otherwise. So a correct wikipedia build looked exactly like a build where the knob did nothing.

   It now prints the real host, run through the ASCII→PETSCII translator so en.wikipedia.org renders as letters rather than graphics characters (that's issue #28's path).

   2. make HTTPS_HOST=... could genuinely do nothing, and exit 0

   Your first command had no make clean, and that path had a real bug. macOS ships GNU Make 3.81, which compares timestamps at 1-second resolution. If boot.o gets rebuilt in the same second as the previous link, it doesn't count as newer than the PRG, so the link is skipped — no output, exit 0, and build/c64-https.prg still carries the old host.

   Reproduced here exactly. Fixed by doing the compare-and-invalidate during Makefile parse rather than in a recipe (an intermediate attempt that deleted the PRG from inside the recipe was worse — make had already cached its stat, so it skipped the link and left no PRG at all, still exit 0).

   Verified 3/3 on the same-second switch in both directions.

   One thing to check on your side

   You mentioned running c64-https-uci-comb.prg. That name is a release artifact produced by make package into dist/ — it is built with the default host and knows nothing about your HTTPS_HOST=.

   make HTTPS_HOST=... HTTPS_PATH=... writes build/c64-https.prg, and that is the file tools/uci/rig_https_wiki.py loads (line 135). If you run the dist/ image, it will connect to foo.bar no matter what you pass to make — that part is working as designed, and worth double-checking is not what happened in your second attempt.

   Verified

   • Same-second host switch without make clean: 3/3 produce an image containing en.wikipedia.org and no foo.bar at all.
   • All five profiles build your command, with the host byte-checked inside the image rather than just linked.
   • A link that overflows now leaves no PRG behind, instead of leaving the previous one for you to run by accident.
   • VICE suites: test_http 66/66 (uci) and 61/61 (ip65), test_tls_handshake 21/21.

   Not verified: no U64E run this session, so the banner is confirmed by inspecting the bytes in the image, not by reading a real screen. If it still shows the wrong host on hardware after a make clean rebuild, reopen and I'll chase it.
4. JC-000

   added a commit that references this issue on Aug 22, 2026

   Merge pull request #130 from JC-000/test/banner-hardware-rig

   ...

   aa50713