Week 09 · overview
Week 9: Names, Requests, and Trust on the Web Path
A browser request can fail even when IP routing works and a TCP port is reachable. Name resolution, HTTP semantics, TLS identity, certificates, time, and application behavior all add dependencies above the basic network path.
This week follows one fictional web request from name to encrypted application response and teaches you to diagnose the first failed layer instead of calling every symptom “the internet.”
This week
- DNS Maps Names to Data, Not Trust — read a supplied DNS answer and separate name resolution from identity/security claims.
- HTTP Is a Request/Response Protocol — interpret method, path, status, headers, and application-layer evidence.
- TLS Protects a Session Under Specific Trust Conditions — reason about certificate name, validity, trust roots, and encrypted transport without treating the padlock as magic.
Evidence artifact
Create a Web Path Evidence Stack from DNS → route/transport → TLS → HTTP, including one failure, one repair in the fictional model, and a bounded end-to-end claim.