The parks inventory client raises a local socket read deadline before any HTTP status line arrives from Meraki. How does that event differ from receiving an HTTP 408 response body?
Select an answer to reveal the explanation.
Short Explanation
One clock is on your wrist; the other is a reply letter from city hall. A local read deadline rings before any status arrives. A 408 is the server answering with a timeout status and body.
Full Explanation
A client-enforced socket read deadline that fires before any HTTP status line arrives is a local failure: the parks inventory client aborted waiting; Meraki never delivered a status line or body on that attempt. An HTTP 408 is different in kind: it is a server-generated response with a status line and typically a body saying the server timed out waiting on the client or declared a request timeout. One is your clock; the other is a protocol response.
Treating both as identical because “every timeout is always 408” collapses local abort and server response into one event and mis-teaches troubleshooting. Claiming a client deadline means the server already returned 408 assumes a status line that, by the stem, never arrived. Saying a 408 can only be produced by the client’s DNS resolver invents a nonsensical source—DNS failures are not HTTP 408 from origin.
Exam caveat: some intermediaries may inject timeouts differently; still distinguish “no response yet” client aborts from numbered HTTP statuses. Operational check: log whether the exception is a local timeout/socket error versus an HTTP response with status_code; for Meraki inventory pulls, only the latter yields a parseable 408 body.