RFC / HTTP Spec Reference
100% LocalQuick-reference index for web standards and protocols.
HTTP Protocol Reference
Search and explore RFC specifications for modern web development.
Protocol Explorer
The HTTP protocol is the foundation of the web. Understanding these primitives is essential for building performant and secure APIs. Refer to official IETF RFCs for the definitive specification of each item.
Search RFC numbers or HTTP status codes. Each entry links to the full specification text.
Learn More
What is RFC / HTTP Spec Reference?
Frequently Asked Questions
Technical Deep Dive
RFC / HTTP Spec Reference
An optimized search engine for the RFCs that power the web. Quickly find specifications for HTTP/2, HTTP/3, WebSockets, OAuth2, and security standards with concise summaries and direct links.
Built for Devs
Designed by people who use these tools in production every day.
Smart Defaults
Reasonable assumptions out of the box, every assumption overridable when you need it.
Workflow-Friendly
Pairs with your IDE, CI, and code review, output drops into commits and PRs cleanly.
RFCs: The Source of Truth for Internet Protocols
The Request for Comments series, maintained by the IETF since 1969, is the canonical specification for how the internet works. HTTP, TLS, DNS, OAuth, TCP, IP, all defined in RFCs. When a question is "what does the spec really say about X?", the RFC is the answer. This reference indexes the most-cited RFCs with quick summaries and links to the authoritative documents.
How the RFC Process Works
A new internet protocol typically goes through:
- Internet Draft (I-D): working document, no stable status, expires after 6 months unless revised.
- Working Group review: relevant IETF working group iterates on the draft.
- IESG approval: the Internet Engineering Steering Group approves.
- RFC publication: assigned a number, frozen forever (no edits, corrections come as errata or new RFCs).
- Status progression: starts as Proposed Standard, may advance to Internet Standard after widespread deployment.
An RFC, once published, never changes. If you find a bug, you write a new RFC that "Updates" or "Obsoletes" the old one. The old RFC stays in the archive forever; the new one points to it.
Status Levels
| Status | Meaning |
|---|---|
| Internet Standard | Mature, widely deployed (rare; takes years). |
| Proposed Standard | Active spec; most "real" RFCs are here. |
| Informational | Documentation, not a normative spec. |
| Experimental | Trial protocols. |
| Historic | Deprecated. |
| Best Current Practice (BCP) | Operational guidance, e.g., RFC 8174 (RFC 2119 word capitalization). |
Always check status before relying on an RFC; "Proposed" doesn't mean draft, it means "this is the standard, but not yet certified as such by long use."
Obsoletes / Updates
Every RFC has metadata on its IETF page:
- Obsoletes: this RFC replaces older ones. The old ones are now Historic.
- Updates: this RFC modifies parts of older ones without fully replacing them.
- Obsoleted by: this RFC has been replaced.
- Updated by: parts of this RFC are revised elsewhere.
For HTTP specifically:
- RFC 2616 (1999): old monolithic HTTP/1.1 spec. Obsoleted by 7230-7235.
- RFC 7230-7235 (2014): split into Message Syntax, Semantics, Caching, etc. Obsoleted by 9110-9114.
- RFC 9110-9114 (2022): current HTTP spec. Cleaner organization, version-independent semantics in 9110.
When citing HTTP standards in 2026, cite 9110-9114, not the older ones.
Core RFCs for Web Developers
HTTP
- RFC 9110, HTTP Semantics. The fundamentals: methods, status codes, headers, content negotiation, conditional requests. The most-cited HTTP doc.
- RFC 9111, HTTP Caching. Cache-Control, ETags, conditional requests.
- RFC 9112, HTTP/1.1 Wire Format. The on-the-wire syntax of HTTP/1.1.
- RFC 9113, HTTP/2. Binary framing, multiplexing, header compression (HPACK).
- RFC 9114, HTTP/3. HTTP over QUIC.
- RFC 7540, HTTP/2 (older, obsoleted by 9113).
- RFC 9000, QUIC transport.
URIs and URLs
- RFC 3986, Uniform Resource Identifier (URI) syntax. The grammar for URIs.
- WHATWG URL Standard, browsers' actual URL parsing. More permissive than RFC 3986.
Auth
- RFC 6749, OAuth 2.0 framework.
- RFC 6750, OAuth 2.0 Bearer Token Usage.
- RFC 7519, JSON Web Token (JWT).
- RFC 7515-7518, JWS, JWE, JWA, JWK (JOSE family).
- RFC 8628, OAuth 2.0 Device Authorization Grant (for TVs, CLIs).
- RFC 7636, PKCE (Proof Key for Code Exchange), critical for OAuth on public clients.
- OpenID Connect Core, not an RFC, but the standard on top of OAuth for authentication.
TLS / Crypto
- RFC 8446, TLS 1.3 (current).
- RFC 5246, TLS 1.2 (older but still common).
- RFC 7748, Curve25519, Curve448.
- RFC 8032, Ed25519, Ed448.
- RFC 5280, X.509 PKI certificates.
- RFC 5321, SMTP.
- RFC 5322, Internet Message Format (email headers/bodies).
- RFC 6376, DKIM.
- RFC 7208, SPF.
- RFC 7489, DMARC.
WebSockets
- RFC 6455. The WebSocket Protocol.
JSON
- RFC 8259, JSON. Yes, JSON has an RFC. Defines syntax precisely.
- RFC 7159 (obsoleted by 8259).
DNS
- RFC 1034, 1035, DNS foundations (still current as of 2026).
- RFC 8484, DNS over HTTPS (DoH).
- RFC 7858, DNS over TLS (DoT).
Misc Useful
- RFC 2119, "MUST / SHOULD / MAY" keywords. Updates 8174.
- RFC 3339, Internet date/time format (ISO 8601 subset).
- RFC 5424, Syslog protocol.
- RFC 6585, Additional HTTP status codes (introduces 429 Too Many Requests).
- RFC 7807, Problem Details for HTTP APIs.
- RFC 7946, GeoJSON.
- RFC 2606, Reserved TLDs (
.test,.example,.invalid,.localhost). - RFC 5737, IPv4 documentation ranges (
192.0.2.0/24etc.).
Reading an RFC Efficiently
RFCs are dense. Strategy:
- Abstract: 1-paragraph overview. Read first.
- Introduction: motivation, scope. Often skippable if you already know why.
- Terminology section: critical, definitions of terms used precisely throughout.
- Table of contents: scan to find the section you need.
- Specific section: read carefully.
- Security Considerations: required in every RFC; often illuminating about real-world attacks.
- IANA Considerations: registry assignments; usually skip.
For protocol RFCs, look for ABNF grammar (formal syntax). For algorithm RFCs, look for the algorithm pseudo-code sections. Skim everything else.
"MUST / SHOULD / MAY"
RFC 2119 defines the requirement keywords. Always uppercase:
- MUST / REQUIRED / SHALL: an absolute requirement. Violating breaks the spec.
- MUST NOT / SHALL NOT: absolute prohibition.
- SHOULD / RECOMMENDED: do this unless you have a very good reason not to. Implementations may differ.
- SHOULD NOT / NOT RECOMMENDED: avoid this unless very good reason.
- MAY / OPTIONAL: implementations choose.
This precise language is essential for interoperability. When reading an RFC, look at the keywords carefully, "SHOULD X" and "MUST X" mean very different things to implementers.
Where RFCs Live
Datatracker (datatracker.ietf.org): authoritative metadata, working group history, drafts.
RFC Editor (rfc-editor.org): the final published RFCs, multiple formats (TXT, HTML, PDF).
IETF Search (datatracker.ietf.org/doc/search/): cross-reference search.
For browsing: rfc.io and tools.ietf.org have nicer HTML renderings; the official RFC Editor is now also HTML-friendly (since RFC 7990).
Beyond RFCs
The web isn't just RFCs. Other standards bodies:
- WHATWG (whatwg.org): HTML, DOM, Fetch, URL, Encoding. Living standards.
- W3C (w3.org): CSS, ARIA, WebGL, WebRTC, SVG. Versioned recommendations.
- TC39 (tc39.es): ECMAScript / JavaScript language. Yearly editions.
- Khronos: WebGL, WebGPU low-level GPU specs.
For browsers: WHATWG and W3C dominate the web-platform side; RFCs cover protocols beneath.
Privacy
This is an index of RFC titles, summaries, and tags pre-loaded into the page. Your searches and filtering happen entirely in the browser, no query is sent anywhere. Open DevTools Network during use: zero outbound requests (until you click an RFC link to visit ietf.org, where the request is between you and IETF, not via this tool). Your search topics, sometimes signaling what protocols/security mechanisms you're investigating, stay private.