Exercise 1: Why a 500 Error Report Is Good Evidence — Possible Solution
====================================================================

WHY THIS COUNTS AS GOOD EVIDENCE, NOT JUST BAD NEWS
------------------------------
Per this chapter's finding-box, "receiving an HTTP status code back at
all - even a 500 - is only possible once DNS resolved (Chapter 4), the
network path worked (Chapter 5), the port accepted a connection
(Chapter 6), and, for HTTPS, the TLS handshake completed successfully
(this chapter). None of that could have happened if any lower rung had
actually failed." A 500 error page is itself proof a full HTTP
response was successfully transmitted and received - which requires
every one of those earlier steps to have already succeeded.

WHAT IT SPECIFICALLY CONFIRMS
------------------------------
Per this chapter: DNS resolution succeeded, the network path to the
server is working, the correct port accepted the TCP connection, and
(if the site uses HTTPS) the TLS handshake completed without error.
All four of Chapter 2's lower rungs are confirmed in one report,
without needing to test any of them separately.

WHY THIS NARROWS THE REMAINING INVESTIGATION
------------------------------
Per this chapter, "the remaining question is narrower than it sounds" -
since four of the five rungs are already ruled out, the only place left
to look is the application itself, which is exactly the kind of
problem this chapter hands off to Logging & Log Analysis (log1) to
actually diagnose.

WHY THIS WORKS AS AN ANSWER
------------------------------
It explains specifically why receiving any HTTP response - even an
error - requires every lower rung to have already succeeded, and
connects that to how much of the investigation it already rules out,
rather than treating "got an error" as simply bad news with no
diagnostic value.