What Every Web Framework Actually Does
A foundational paper on the universal pattern underlying all HTTP application development — independent of language, platform, or framework.
Paper 1: The Universal Web Processing Model — What Every Web Framework Actually Does
Paper 2: Rewriting the ASP.NET Web Forms Engine — Freeing the Pattern from the Container
Paper 3: The Composable Web Host — One Host, Many Engines
Paper 4: The .NET Web Host
Paper 5: The Universal Web Host
Preamble
Every web application ever built — regardless of programming language, operating system, framework, or era — performs the same fundamental operations. This is not a design philosophy. It is not an architectural preference. It is the mechanical reality of the HTTP protocol itself.
Whether built in C#, Java, Python, PHP, Rust, Go, Node.js, Ruby, C++, or any language yet to be written — the processing model is identical. The protocol does not care how you organize your code. It cares only that a request was received and a response was returned.
This paper names that model. Not as a new invention, but as a recognition of what has always existed — beneath every framework, inside every server, present in every HTTP exchange since the protocol was first specified.
The Seven Operations
Strip away every framework name. Forget every library, every architectural pattern, every brand. What remains is this: a client sends a message to a server. The server processes it and sends a message back.
That exchange, at its mechanical core, involves exactly seven operations — universally present, universally ordered:
- Accept — Listen on a network socket. Accept the incoming connection.
- Parse — Read the raw bytes and extract their structure: the method, the path, the headers, the query string, the body.
- Route — Determine which code should handle this request.
- Execute — Run that code. Accept input. Produce output.
- Respond — Serialize the output — a status code, headers, and a body — and write it back to the connection.
- Persist — Optionally, maintain the connection as an open channel for ongoing communication: bidirectional (WebSocket) or server-push (Server-Sent Events).
- Release — Close the connection, or return it to a pool for reuse.
No web application omits any of these operations. No web application reorders them. They are not a convention. They are the protocol.
We refer to this sequence as the Universal Web Processing Model (UWPM).
The Pipeline
The following diagram illustrates the seven operations and the natural boundary between them. Operations 1, 2, 5, 6, and 7 are infrastructure — they deal with the network, the protocol, and the connection. Operations 3 and 4 are application logic — they deal with what your code actually does.
This boundary is the single most important observation in this paper. The only difference between all web frameworks in existence is how they implement operations 3 and 4. Every other operation is identical across all implementations, all languages, and all platforms.
The Two Roles
The Host
Operations 1, 2, 5, 6, and 7 belong to the Host. The host owns the socket. It speaks the HTTP protocol. It parses incoming bytes into structured data, writes structured responses back to the wire, manages connection lifecycle, handles TLS encryption, and provides the persistent channel infrastructure for WebSocket and Server-Sent Events.
The host is not a framework. It is a platform. It provides the universal operations so that application code never needs to think about TCP, byte parsing, or connection management. Every web server ever built — regardless of its name or origin — is a host.
The Handler Engine
Operations 3 and 4 belong to the Handler Engine. The handler engine receives a parsed request — already structured into method, path, headers, and body — and produces a response. It decides which code runs (routing) and what that code does (execution).
The handler engine knows nothing about sockets, byte streams, or connection pools. It operates purely at the level of application logic. Every web framework ever built — regardless of its name or origin — is a handler engine.
Some systems blur this boundary by bundling a host and an engine together. Some make the boundary explicit. But the boundary always exists — because the protocol demands it. The network operations and the application operations are fundamentally different concerns, and every system separates them, whether it acknowledges the separation or not.
The Universality Principle
The Universal Web Processing Model is not bound to any programming language, runtime, platform, operating system, or framework. It describes the processing model inherent in the HTTP protocol itself.
A web server written in C performs these seven operations. So does one written in Rust. A web application built in Python, PHP, Java, C#, Go, Node.js, Ruby, or any language that speaks HTTP — performs these seven operations. The language determines the syntax of the implementation. The protocol determines the structure.
This universality is not a claim. It is a consequence. The HTTP specification defines a request-response model. Any system that implements this model must accept connections, parse requests, determine what to do, do it, and send a response. There is no alternative sequence. There is no shortcut. The seven operations are the minimum complete description of HTTP processing.
Frameworks, therefore, are not fundamental architectures. They are handler engine implementations — specific answers to the question of how operations 3 and 4 should be organized. They differ in routing strategy, execution model, state management, and rendering philosophy. But they all receive the same parsed request. They all produce the same structured response. They all plug into the same pipeline.
The Composition Principle
If the handler engine is a modular component responsible only for routing and execution, then a natural architectural possibility emerges: multiple handler engines can coexist under a single host.
A host that understands the boundary between infrastructure and application logic can load more than one engine. A configuration layer — a simple dispatch table mapping URL path patterns to engine identifiers — directs each incoming request to the appropriate engine. One path pattern is handled by one engine. Another pattern is handled by a different engine. A default engine catches everything else.
Under this model, the handler engine ceases to be a platform. It becomes a plugin. The host becomes the platform. And the developer regains the freedom to choose, combine, and replace engines without rebuilding their infrastructure.
New engines can be invented without building new servers. Legacy engines can be preserved without maintaining legacy servers. Multiple architectural philosophies can coexist under one roof, serving the same application, sharing the same network infrastructure.
The Idea
The Universal Web Processing Model is not a new idea. It is the idea that was always there — beneath every framework, inside every server, present in every HTTP exchange since the protocol was first specified.
This paper names it. The architecture follows.