When Yorick Peterse recently implemented an HTTP 1.1 stack for Inko's standard library, he encountered a sobering reality: despite three decades of web evolution, form handling remains a fragmented, underspecified mess. His deep dive reveals why these critical components of web infrastructure are still mired in design flaws that create unnecessary complexity for developers.

The Protocol Quirks No One Asked For

HTTP 1.1's eccentricities start at the foundation. Consider chunked transfers: while streaming data in segments is sensible, the RFC mandates hexadecimal chunk sizes instead of decimal—forcing 4D2 instead of 1234. Then there's the status line requirement: HTTP/1.1 200 is invalid without the trailing space after the status code, a syntax landmine that has broken real implementations.

"HTTP 1.1's RFCs read like archaeological records of implementation accidents rather than intentional design," Peterse observes. "Forms exemplify this technical debt."

Form Encoding: Two Flawed "Standards"

1. application/x-www-form-urlencoded: The Underspecified Legacy

  • No Formal Spec: Neither RFC 9110 nor 9112 defines it. Implementations rely on RFC 3986's query string rules by convention.
  • Inconsistent Encoding: A value like "😀" might be percent-encoded differently across clients/servers.
  • Array Ambiguity: Is it numbers[]=1&numbers[]=2 or numbers=1&numbers=2? No standard exists.
  • Size Bloat: URL-encoding non-ASCII data can triple payload sizes—disastrous for file uploads.
# Example: Inconsistent array representations
numbers[]=1&numbers[]=2  # Some frameworks
numbers=1&numbers=2       # Others

2. multipart/form-data: The Overengineered Alternative

Defined in RFC 7578, this email-inspired format introduces new headaches:
- Boundary Collisions: Randomly generated separators (e.g., ----WebKitFormBoundaryzXKfCo7) must hope not to appear in payloads.
- Parsing Complexity: Efficiently detecting boundaries within values requires state machines, not simple delimiters.
- Header Bloat: Each field carries headers like Content-Disposition and Content-Type—redundant for most use cases.
- No Structured Data: Arrays and objects lack standardized representations.

--BOUNDARY
Content-Disposition: form-data; name="name"

Alice
--BOUNDARY
Content-Disposition: form-data; name="file"; filename="test.txt"
Content-Type: text/plain

Hello World
--BOUNDARY--

Why Hasn't This Been Fixed?

Despite HTTP/2 and HTTP/3 modernizing the transport layer, form handling remains stuck in the 1990s. A 2014 W3C proposal for JSON form encoding was abandoned. Alternatives like tus for resumable uploads exist but lack browser integration for mixed form data. The result? Developers waste cycles on:

  1. Writing custom parsers for underspecified formats
  2. Debugging boundary collision edge cases
  3. Mitigating performance pitfalls from encoding bloat

"After 30 years, we're still submitting forms like it's 1985," Peterse laments. Until browsers and RFCs prioritize modernizing this critical path, the mess will persist—a testament to the web's stubborn legacy baggage.

Source: Yorick Peterse