Web Standards
Percent-Encoding
Percent-encoding is the URI mechanism that replaces a byte with `%` plus two hexadecimal digits so characters with special syntactic meaning, or bytes outside ASCII, can be carried inside a URL without ambiguity.
RFC 3986
RFC 3986 (2005) is the IETF specification that defines the generic syntax of Uniform Resource Identifiers, superseding RFC 2396 and RFC 1738 and serving as Internet Standard 66.
JSON
JavaScript Object Notation — a lightweight, text-based data interchange format derived from a subset of JavaScript syntax, standardized as ECMA-404 and RFC 8259.
HTTP
The Hypertext Transfer Protocol (HTTP) is the application-layer protocol that underlies the World Wide Web. Clients send method-based requests (GET, POST, PUT, DELETE, HEAD, etc.) over TCP or QUIC, and servers reply with a status code, headers, and an optional body. HTTP/1.1 remains widely deployed, with HTTP/2 multiplexing and HTTP/3 over QUIC layering performance improvements on the same semantic model.
SMTP (Simple Mail Transfer Protocol)
Text-based protocol for relaying email between {{Mail Transfer Agent}}s, originally specified by {{Jon Postel}} in RFC 821 (August 1982) alongside {{RFC 822}}, and updated to RFC 5321 in 2008; it carries the message envelope while RFC 5322 governs the message content.
HTML5
The fifth major version of HTML, originating as WHATWG's Web Applications 1.0 draft and adopted by the W3C in 2007. Reached Recommendation status in 2014. Designed for backwards compatibility, precisely specified error recovery, and a large feature surface (video, canvas, semantic elements, offline storage). Stewardship passed entirely to WHATWG in 2019 as the HTML Living Standard.
WHATWG
The Web Hypertext Application Technology Working Group, founded 4 June 2004 by Apple, Mozilla, and Opera after W3C rejected a pragmatic HTML extension proposal. WHATWG's principles — backwards compatibility, specified error recovery, and continuous evolution — produced HTML5 and the Living Standard model. Since 2019 it is the sole publisher of HTML and DOM standards.
Base64 Encoding
Binary-to-text encoding that maps every 3 input bytes (24 bits) to 4 printable ASCII characters drawn from a 64-character alphabet, used by {{MIME}} to carry binary data through 7-bit-clean mail transports and widely reused for embedding small blobs in JSON, URLs, and HTTP headers.
401 Unauthorized vs 403 Forbidden
401 means the request lacks valid authentication; 403 means the caller is authenticated but not permitted. RFC 9110 makes the distinction explicit and requires a WWW-Authenticate header on 401.
IANA
The Internet Assigned Numbers Authority (IANA) coordinates global allocation of internet number resources, root DNS, protocol parameters, and the tz time zone database. It operates under ICANN.
REST API
An API style built on the constraints of Representational State Transfer, using stateless HTTP requests, resource-oriented URLs, and standard verbs to manipulate representations of resources.
XML
Extensible Markup Language — a W3C-standardized markup format with named tags, attributes, and namespaces, designed in the late 1990s for self-describing, human-readable structured data interchange.
HTTP Caching
HTTP caching reuses prior responses to cut latency, bandwidth, and origin load. Cache-Control directives govern storage and freshness; ETag and Last-Modified validators enable conditional requests that return an empty 304 Not Modified when content has not changed. Caches form a hierarchy from browser through proxy or CDN to origin, and the Vary header tells caches which request headers participate in the cache key.
ETag
An ETag (entity tag) is an opaque HTTP response header that identifies a specific version of a resource. Clients echo it back in If-None-Match to perform a conditional request, letting the server return 304 Not Modified when the cached copy is still current. ETags come in strong and weak forms, with weak tags prefixed W/ and indicating only semantic equivalence.
WHATWG URL Standard
The WHATWG URL Standard is a living specification that defines URL parsing, serialisation and encoding for the modern web, intended to describe what browsers actually do rather than the abstract grammar of RFC 3986.
MIME Sniffing
MIME sniffing is the browser practice of inspecting a response's initial bytes to guess its format when the Content-Type header is missing or wrong. It enabled compatibility with poorly configured servers but introduced cross-site scripting risks, which the X-Content-Type-Options: nosniff header and the WHATWG mimesniff specification exist to constrain.
Media Type Registration
Media type registration is the RFC 6838 process for adding new MIME / media type identifiers to the IANA registry. RFC 6838 defines four namespace trees (standards, vendor, personal, unregistered), an email-driven submission workflow with designated expert review, a provisional registration mechanism, and structured suffixes like +json and +xml that compose serializations onto format identifiers.
Why URL Encoding Is So Confusing
URL encoding tangles three different rule sets: RFC 3986 percent-encoding for URIs, application/x-www-form-urlencoded for HTML forms (where + means space), and the WHATWG URL Standard's context-specific encode sets. The mismatches explain bugs like + in Gmail addresses, double-encoded %2520, and URLs that work in a browser but break in curl.
MIME (Multipurpose Internet Mail Extensions)
Set of standards (RFCs 2045-2049, 1996) that extends the plain-ASCII {{RFC 822}} mail format to carry binary attachments, non-ASCII character sets, and multipart messages by adding Content-Type, Content-Transfer-Encoding, and MIME-Version headers.
Retry-After Header
An HTTP response header telling a client how long to wait before retrying. Used with 429 Too Many Requests, 503 Service Unavailable, and some 3xx redirects. Value is either delay-seconds or an HTTP-date.
Quoted-Printable Encoding
{{MIME}} content-transfer-encoding that leaves printable ASCII bytes as-is and escapes everything else as =XX hex pairs, used for mostly-Latin text with occasional non-ASCII characters so the encoded form remains roughly human-readable.
HTTP Status Codes: When You Actually See Each One
A practitioner's guide to the HTTP status codes that actually appear in production: the everyday 2xx, the method-preserving distinction between 301/302 and 307/308, conditional 304s, the 400-vs-422 and 401-vs-403 and 404-vs-410 confusions, 429 with Retry-After, and which of 500/502/503/504 comes from the load balancer versus the origin.
XHTML
XML-based reformulation of HTML. XHTML 1.0 (2000) recast HTML 4.01 under XML syntax rules; XHTML 1.1 (2001) modularized it. Adoption was undermined by draconian error handling and by authors serving XHTML as text/html so browsers ignored XML rules. XHTML 2.0's clean-break redesign was abandoned in 2009. XHTML survives as XHTML5, an XML serialization of HTML5.
SOAP
Simple Object Access Protocol — an XML-based messaging protocol for web services, standardized at the W3C in 2000, foundational to the WS-* enterprise stack.
Why Unicode Has Four Normalization Forms
Unicode permits more than one byte sequence to represent the same visible string, so the standard defines four normalization forms — NFC, NFD, NFKC, and NFKD — that collapse those alternatives to a single canonical shape. The pair NFC/NFD handles canonical equivalence (precomposed vs. decomposed accents), while NFKC/NFKD additionally fold compatibility variants like ligatures and full-width letters. Each form has a niche: storage and display, sorting and linguistic processing, or loose search and matching.
Conditional GET
A conditional GET is an HTTP request that asks the server to send the resource only if a condition on a validator (ETag via If-None-Match, or Last-Modified via If-Modified-Since) is met. When the cached copy is still current, the server returns 304 Not Modified with no body, saving bandwidth while letting the client reuse its stored representation.
Why MIME Types Are A Mess
MIME types (formally internet media types) classify content with strings like `text/html` or `application/json`, registered with IANA under the four-tree scheme of RFC 6838. In practice the system is messy: the vendor tree is bloated with proprietary identifiers, legacy quirks like the deprecation and 2022 reinstatement of `text/javascript` confuse implementers, server defaults often mislabel files, useful types are missing for many code languages, and browser MIME sniffing introduced a class of cross-site scripting risks that the `nosniff` header was created to mitigate.
Why XHTML 2.0 Was Abandoned
W3C's XHTML 2.0 effort (2002-2009) tried to redesign HTML as a clean, strict, non-backwards-compatible XML language with draconian error handling. The WHATWG breakaway in 2004 (Apple, Mozilla, Opera) produced HTML5 instead: pragmatic, backwards-compatible, and explicit about error recovery. W3C killed XHTML 2 in 2009 and adopted HTML5. The lasting lesson: on the web, breaking compatibility for purity loses to backwards-compatible incrementalism.
Why Email Headers Look the Way They Do (RFC 822 to RFC 5322)
The colon-delimited plain-text header format used by every email today traces directly to {{RFC 733}} (1977) and {{RFC 822}} (1982), preserved through {{RFC 2822}} (2001) and {{RFC 5322}} (2008) for backwards compatibility with the entire installed mail ecosystem.
Why XML Lost to JSON for Web APIs
Between 2005 and 2015 the default wire format for public web APIs flipped from XML/SOAP to JSON/REST. The shift was driven less by feature parity than by verbosity, browser-native parsing, and the WS-* stack's ceremony — but XML still dominates SAML, financial reporting, and structured publishing where its schema and signature semantics remain unmatched.