📡 ToastRFC

The internet's standards,
made studyable.

RFCs are a graph, not a book — "obsoleted by 9110", "updated by", "see §4.2". ToastRFC shows the graph: every requirement tappable, every cited RFC linked, a glossary that tracks MUST / safe / idempotent across the spec and across the versions that redefined them, plus paths and self-test decks.

Phase 0 · the HTTP core · 3 RFCs · 2106 units · 12 concepts · 154 edges · 4 paths · 19 cards. Scope →

In this reader

RFC 9110 · STD 97 HTTP Semantics The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext informa… RFC 9111 · STD 98 HTTP Caching The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext informa… RFC 9112 · STD 99 HTTP/1.1 The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext informa…

Start here

What actually governs HTTP today The 2022 core (RFC 9110/9111/9112) replaced a decade of RFCs. Here's the lineage and why it was redone. The requirement keywords: MUST, SHOULD, MAY Every IETF spec runs on these words. Reading them wrong is the #1 way implementations diverge. Safe, idempotent, cacheable — the method property grid Why you can retry a PUT but not a POST, why a crawler can GET freely, and what a cache is allowed to keep. You never GET a resource Resource vs representation vs message — the abstraction that makes content negotiation, caching, and ETags all make sense.

Concepts

MUST / REQUIRED / SHALL an absolute requirement of the specification — no conforming implementation may do otherwise SHOULD / RECOMMENDED there may be valid reasons to ignore this in particular circumstances, but the full implications must be understood and weighed MAY / OPTIONAL genuinely optional — one implementation may do it, another may not, and both conform; neither side may assume the other's choice safe method a method whose defined semantics are essentially read-only — the client does not request, and cannot be held responsible for, any change on the server idempotent method the intended effect on the server of multiple identical requests is the same as for a single such request cacheable a response is cacheable if a cache is allowed to store a copy and reuse it for a later request resource the target of an HTTP request, identified by a URI — anything that can be named representation information intended to reflect a resource's state, in a format that can be communicated in a message — bytes plus metadata