## §SELF — miscsubjects (paste without context)

**Principle:** Self-explaining payload — no external context required. This _self block describes what you are reading and where to look next.

**This widget:** `article_bundle` — **LLM article bundle**
Paste-ready package: body + claims + sources + voxels + provenance + manifest + constitution.
- **article slug:** `oip-what-is-http`
- **contains:** body, claims, sources, voxels, provenance, question graph, constitution, llm_manifest
- **how to use:** Paste entire block into Grok/GPT/Gemini. Section §SELF explains the system.
- **read:** https://miscsubjects.com/api/articles/oip-what-is-http/bundle?format=markdown

### Logical proof (verify each step)
1. Articles are voxel graphs of tiered claims, not prose blobs. → https://miscsubjects.com/api/articles/constitution
2. Claims link to hash-chained sources via source_ids. → https://miscsubjects.com/api/articles/oip-what-is-http/sources
3. Ask reads topology; ingest/claim append to ledger. → https://miscsubjects.com/api/protocol
4. Models queue growth: populate → collaborate → repair → reflex. → https://miscsubjects.com/api/protocol/grow
5. Graph proves its own shape (reflex) and $/claim (yield). → https://miscsubjects.com/graph.html?layer=reflex
6. Full feature index + _explain on every API response. → https://miscsubjects.com/api/articles/system-map

### Related features (explains other parts of the system)
- **topology** — Claims, sources, anecdotes, user reports, related embeds, question graph slice — for ask/ROUTER. · https://miscsubjects.com/api/articles/oip-what-is-http/topology
- **voxels** — Claims as atoms, sources as edges (supported_by, posted_by). Per-claim provenance. · https://miscsubjects.com/api/articles/oip-what-is-http/voxels
- **ask** — Answer only from topology; creates question_node with gaps and ingest_hint. · https://miscsubjects.com/api/articles/oip-what-is-http/prompts
- **ingest** — Parse pasted evidence → source ledger + claims + evidence_ingest node.
- **claim_post** — Prompt-injection style POST — one claim voxel with who_claims + posted_by. · https://miscsubjects.com/api/articles/oip-what-is-http/voxels
- **llm_manifest** — Machine-readable read/write contract for external LLMs. · https://miscsubjects.com/api/articles/llm-manifest

### Full index
- JSON: https://miscsubjects.com/api/articles/system-map
- Markdown: https://miscsubjects.com/api/articles/system-map?format=markdown

*Not medical advice. Tier-honest. Cite claim/source ids.*

---

# miscsubjects article bundle

> Paste this entire block into Grok, GPT, or Gemini. They can READ the ledger below and RETURN evidence via ingest (see § LLM manifest).

## Article
- **slug:** `oip-what-is-http`
- **title:** What Is HTTP
- **url:** https://miscsubjects.com/a/oip-what-is-http
- **register:** oip_protocol
- **updated:** 2026-07-04T19:01:05.334Z
- **tags:** oip, protocol

## Body

# 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`

2. **Headers**: key-value pairs that describe the request.
   `Host: api.example.com`
   `Accept: application/json`
   `Authorization: Bearer token123`

3. **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`

2. **Headers**: metadata about the response.
   `Content-Type: application/json`
   `Content-Length: 234`

3. **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":"ada@example.com"}
```
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/philosophy) — a living system of self-describing voxels that serves the Grain philosophy. The OIP is the interface. The philosophy is the core.


## Claims (0)


## Voxel graph (0 atoms · 0 edges)
- full graph: https://miscsubjects.com/api/articles/oip-what-is-http/voxels

## Article constitution

- full: https://miscsubjects.com/api/articles/constitution

## Source ledger (0)
- chain valid: yes · head: `genesis`

## Provenance (0 model passes)
- chain valid: yes · head: `genesis`


## Question graph
- questions: 0 · evidence ingests: 0

## LLM manifest — how to communicate with this ledger

- system map: https://miscsubjects.com/api/articles/system-map?format=markdown
- topology (ranked): https://miscsubjects.com/api/articles/oip-what-is-http/topology
- ingest: POST https://miscsubjects.com/api/protocol/ingest
- claim: POST https://miscsubjects.com/api/protocol/claim

### Quick actions for this article
- **Read live:** https://miscsubjects.com/api/articles/oip-what-is-http/topology
- **Ask (API):** POST https://miscsubjects.com/api/protocol/ask `{"slug":"oip-what-is-http","question":"..."}`
- **Ingest your findings:** POST https://miscsubjects.com/api/protocol/ingest or text `ingest oip-what-is-http|your evidence`
- **Post one claim:** POST https://miscsubjects.com/api/protocol/claim or text `claim oip-what-is-http|tier|assertion`
- **iMessage ask:** `oip-what-is-http|your question`
- **System map:** https://miscsubjects.com/api/articles/system-map?format=markdown


---

## §SELF — miscsubjects (paste without context)

**Principle:** Self-explaining payload — no external context required. This _self block describes what you are reading and where to look next.

**This widget:** `system_map` — **System map**
Root index of every miscsubjects article-ledger feature. Start here if you have zero context.
- **article slug:** `oip-what-is-http`
- **contains:** body, claims, sources, voxels, provenance, question graph, constitution, llm_manifest
- **how to use:** Root index of every miscsubjects article-ledger feature. Start here if you have zero context.
- **read:** https://miscsubjects.com/api/articles/system-map

### Logical proof (verify each step)
1. Articles are voxel graphs of tiered claims, not prose blobs. → https://miscsubjects.com/api/articles/constitution
2. Claims link to hash-chained sources via source_ids. → https://miscsubjects.com/api/articles/oip-what-is-http/sources
3. Ask reads topology; ingest/claim append to ledger. → https://miscsubjects.com/api/protocol
4. Models queue growth: populate → collaborate → repair → reflex. → https://miscsubjects.com/api/protocol/grow
5. Graph proves its own shape (reflex) and $/claim (yield). → https://miscsubjects.com/graph.html?layer=reflex
6. Full feature index + _explain on every API response. → https://miscsubjects.com/api/articles/system-map

### Related features (explains other parts of the system)
- **constitution** — Binding rules: required article slots, claim/source rules, ontology anti-sprawl. · https://miscsubjects.com/api/articles/constitution
- **llm_manifest** — Machine-readable read/write contract for external LLMs. · https://miscsubjects.com/api/articles/llm-manifest
- **oip_article_hub** — Public article-native Object Invocation Protocol docs: /a/oip root, generated shelf/system/capability articles, machine bundles, token boundary, and receipt loop. · https://miscsubjects.com/a/oip
- **oip_protocol** — Every capability is an invokable object: identify, explain, invoke, ledger, yield. · https://miscsubjects.com/a/oip
- **bundle** — Paste-ready package: body + claims + sources + voxels + provenance + manifest + constitution. · https://miscsubjects.com/api/articles/oip-what-is-http/bundle?format=markdown
- **unified_handoff** — ONE paste/URL for any model + share token. Same self-explaining pattern as article bundle, but whole build. · https://miscsubjects.com/api/handoff?format=markdown

### Full index
- JSON: https://miscsubjects.com/api/articles/system-map
- Markdown: https://miscsubjects.com/api/articles/system-map?format=markdown

*Not medical advice. Tier-honest. Cite claim/source ids.*