What Is HTTP

HTTP

What It Is

HTTP is the request-response protocol that moves the web. A client sends a structured message. A server returns a structured reply. Nothing more. Nothing less.

Why It Matters

Every web page you load, every API call you make, every form you submit — HTTP carries it. Without HTTP, the internet is just disconnected machines. With HTTP, it becomes a conversation.

The protocol is stateless by design. Each request stands alone. This simplicity is why HTTP scaled from a CERN research project to the backbone of global commerce. No session memory. No hidden state. The entire context lives in the request itself. This is the DNA of open systems: transparent, inspectable, repeatable.

HTTP also embodies layered architecture. It runs over TCP (or QUIC), which runs over IP, which runs over Ethernet. Each layer knows only the layer beneath it. You can swap TCP for QUIC without touching HTTP. You can swap Ethernet for WiFi without touching TCP. This separation of concerns is how systems survive decades of change.

How It Works

A client opens a TCP connection to a server on port 80 (HTTP) or 443 (HTTPS). It sends a request message.

The request has three parts:

1. Request line: method, path, protocol version.

GET /api/user/42 HTTP/1.1

1. Headers: key-value pairs that describe the request.

Host: api.example.com Accept: application/json Authorization: Bearer token123

1. Body (optional): payload for POST, PUT, PATCH.

The server reads the request, processes it, and sends a response.

The response has three parts:

1. Status line: protocol version, status code, reason phrase.

HTTP/1.1 200 OK

1. Headers: metadata about the response.

Content-Type: application/json Content-Length: 234

1. Body: the actual data.

The connection may close or persist for reuse. HTTP/1.1 keeps connections alive by default. HTTP/2 multiplexes multiple requests over one connection. HTTP/3 replaces TCP with QUIC for faster, more resilient transport.

The Contract

REQUEST  = Method SP Request-Target SP HTTP-Version CRLF
           *(Header-Field CRLF)
           CRLF
           [Message-Body]

RESPONSE = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
           *(Header-Field CRLF)
           CRLF
           [Message-Body]

Methods: GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS, TRACE, PATCH.

Status codes are grouped by first digit:

• 1xx: Informational
• 2xx: Success (200 OK, 201 Created, 204 No Content)
• 3xx: Redirect (301 Moved Permanently, 302 Found, 304 Not Modified)
• 4xx: Client Error (400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 429 Too Many Requests)
• 5xx: Server Error (500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable)

Headers are case-insensitive. Body encoding is declared by Content-Type and Content-Length or Transfer-Encoding.

Real Examples

1. Loading a web page

GET / HTTP/1.1
Host: example.com

Response: HTML document. The browser parses it, sees references to CSS, JS, images, and fires additional GET requests for each.

2. Creating a user

POST /api/users HTTP/1.1
Host: api.example.com
Content-Type: application/json

{"name":"Ada Lovelace","email":"[email protected]"}

Response: 201 Created with a Location: /api/users/42 header.

3. Checking if a resource changed

GET /api/config HTTP/1.1
Host: api.example.com
If-None-Match: "abc123"

Response: 304 Not Modified if the ETag matches. No body transferred. This is how caching saves bandwidth.

4. Deleting a record

DELETE /api/users/42 HTTP/1.1
Host: api.example.com
Authorization: Bearer admin_token

Response: 204 No Content — the action succeeded, there is nothing to return.

5. A health check

HEAD /health HTTP/1.1
Host: api.example.com

Response: 200 OK with no body. HEAD is identical to GET but omits the body. Load balancers use this every second.

Common Mistakes

• Treating GET as safe but not idempotent. GET must not change server state. If your GET /api/reset wipes data, you have broken the contract.
• Ignoring status codes. Returning 200 OK with an error body is a lie. The status code is the first thing every client checks.
• Misusing POST. POST is for creation and non-idempotent actions. Use PUT for full updates, PATCH for partial updates, DELETE for removal. Each method has a meaning.
• Forgetting Content-Length. Without it, the client does not know when the body ends. Use chunked encoding for streaming responses where size is unknown.
• Caching POST responses. By default, POST responses are not cacheable. If you cache them, you will serve stale data to the wrong users.

Connection to OIP

HTTP is the prototype of an open, deterministic, auditable protocol. Every message is self-contained and inspectable. You can capture a request, replay it tomorrow, and get the same result. This determinism is the foundation of OIP.

The statelessness of HTTP mirrors the statelessness of pure functions. No hidden context. No side effects (if you follow GET). The entire behavior is visible in the message itself. This is what auditable means: you can read the request and know exactly what should happen.

HTTP also shows how protocols evolve without breaking. HTTP/1.0 to HTTP/1.1 added persistent connections and chunked encoding. HTTP/2 added multiplexing. HTTP/3 added QUIC. Each version is backward-compatible in spirit: the semantics of GET, POST, and 200 OK never changed. The transport improved. The contract held.

This is the OIP philosophy in practice: define a clear contract, make it inspectable, let the implementation improve underneath. Open means anyone can speak it. Deterministic means the same input produces the same output. Auditable means you can see every step. HTTP has been doing this since 1991.

Connection to the Grain Philosophy

This protocol is part of the Open Inventory Protocol — a living system of self-describing voxels that serves the Grain philosophy. The OIP is the interface. The philosophy is the core.