Lab: distinguish an HTTP error from a connection failure

Prepare exactly the server this test needs

Use Bash in the disposable Ubuntu machine, with BusyBox, curl, and iproute2 available. Check command -v busybox, command -v curl, and command -v ss; if a tool is missing, use the reviewed APT workflow before proceeding. busybox --list must include httpd; some BusyBox builds omit it. No language runtime is needed.

Use two terminals inside the same named Linux machine. In terminal A, inspect ss -lnt and confirm nothing is listening on loopback port 8765. If it is occupied, identify it and choose another unused port consistently; do not stop an unrelated process.

study_http_dir=$(mktemp -d)
printf '%s\n' "$study_http_dir"
printf '<h1>Foundations local fixture</h1>\n' > "$study_http_dir/index.html"
cat "$study_http_dir/index.html"
busybox httpd -f -p 127.0.0.1:8765 -h "$study_http_dir"

Continue only if directory creation succeeded. The new directory contains one known public file and no private notes or Git data. -f keeps the process in the foreground so Ctrl-C can stop this exact fixture. -h selects the document directory. Keep this terminal open; the final command occupies it while the server runs.

Compare success and a missing resource

In terminal B, still inside the same Linux machine:

ss -lnt
curl --max-time 3 -i http://127.0.0.1:8765/
printf 'curl exit status: %s\n' "$?"
curl --max-time 3 -i http://127.0.0.1:8765/missing
printf 'curl exit status: %s\n' "$?"

Expect a listener on 127.0.0.1:8765, an HTTP success response containing Foundations local fixture for /, and an HTTP missing-resource response for /missing. Read the actual status lines rather than assuming exact header formatting.

Curl normally returns 0 after receiving either complete HTTP response, even the 404. Its process status describes the transfer; the server's HTTP status describes the requested resource. The second request therefore shows that the listener and HTTP exchange worked even though that path did not exist.

Change one condition and repeat the original request

In terminal A press Ctrl-C to stop this BusyBox process. In terminal B, repeat:

ss -lnt
curl --max-time 3 -i http://127.0.0.1:8765/
printf 'curl exit status: %s\n' "$?"

Expect no fixture listener and a connection failure, commonly refusal with curl status 7. There should be no HTTP response because no server accepted this connection. If another listener appears or the request still works, investigate that observation rather than claiming the expected failure.

Fill the table with your actual observations. This test intentionally uses an IP and plain HTTP so DNS and TLS do not obscure the difference being taught. Perform the DNS bite's lookup separately; do not claim the loopback fixture tested either DNS or certificate validation.

Cleanup and transfer the reasoning

In terminal A, where study_http_dir is still defined, confirm the printed path matches the fixture and remove only its entries:

rm -- "$study_http_dir/index.html"
rmdir "$study_http_dir"

No firewall rules changed. Keep the same loopback bind for the MicroBank evidence-page fixture. Explain why a 404 should lead you toward a path/content check, while a refusal should lead you toward listener/address/port checks. A timeout has additional possible causes and was not deliberately reproduced here.

Apply this to MicroBank

Name the successful page, missing path, and stopped-listener results in your MicroBank readiness record. This BusyBox server is a static learning fixture; it does not imitate the Accounts API. The diagnostic method transfers: distinguish a failed connection from an HTTP error, then inspect the specific component. The full transaction check comes in DevOps Foundations.

Keep this observation in the MicroBank readiness project.

Sources

Primary references: BusyBox httpd usage↗; curl exit/status behavior↗.