HTTP/1.1: The Web's Workhorse

What Problem Does HTTP Solve?

1. Request specific resources (documents, images) from remote servers
2. Describe what you're sending (Is this HTML? An image? JSON?)
3. Handle errors gracefully (What if the resource doesn't exist?)
4. Cache responses to avoid redundant transfers
5. Support different types of operations (read, write, delete)

Flowchart diagram 1

Real-World Analogy

• Request (Order): "I'd like a burger, fries, and a drink" (GET /menu/combo1)
• Request Headers: "Make it a large, no pickles, for here not to-go" (Accept, Content-Type, Cookies)
• Response (Food): The actual food you ordered (Response body)
• Response Headers: "Here's your receipt, it's hot, expires in 30 minutes" (Content-Type, Cache-Control, Set-Cookie)
• Status Code: "Order ready!" (200 OK) or "Sorry, ice cream machine broken" (503 Service Unavailable)

The Solution

How HTTP/1.1 Solved These Problems

1. Persistent Connections (Keep-Alive): One TCP connection handles multiple requests
2. Pipelining: Send multiple requests without waiting for responses (though rarely used due to head-of-line blocking)
3. Chunked Transfer Encoding: Stream data without knowing the total size upfront
4. Host Header: Multiple websites on one IP address (virtual hosting)
5. Cache Control: Sophisticated caching with ETags, Last-Modified, Cache-Control
6. Additional Methods: PUT, DELETE, OPTIONS, TRACE, CONNECT for RESTful operations
7. Content Negotiation: Server adapts response based on client capabilities

• Simplicity: Text-based, human-readable for easy debugging
• Performance: Persistent connections reduce latency by ~50%
• Extensibility: New headers can be added without breaking existing implementations

Flow diagram showing process

Building Your Understanding

The Complete HTTP/1.1 Request-Response Cycle

User clicks link or JS calls fetch()

1. DNS Resolution: Without this, you can't find the server. This is cached by your OS (check with nslookup example.com)
2. TCP Connection: The three-way handshake costs ~50-100ms on typical internet connections. HTTP/1.1's persistent connections mean you only pay this cost once per domain
3. HTTP Request: This is a text-based message - literally readable ASCII characters sent over the wire
4. Server Processing: This is where your application code runs - routing, database queries, business logic
5. HTTP Response: Also text-based with headers + body separated by blank line
6. Connection Reuse: The killer feature - subsequent requests skip steps 1-2, saving 100-200ms per request

HTTP Request Anatomy

Flow diagram showing process

HTTP Response Anatomy

Flow diagram showing process

HTTP Methods: The Decision Tree

Flowchart diagram 6

State Diagram: HTTP Connection Lifecycle

Flow diagram showing process

Deep Technical Dive

Architecture Breakdown

Flowchart diagram 8

1. Client Library serializes your request object into raw HTTP text
2. TCP Socket breaks the text into TCP segments and adds headers
3. Network routes packets (IP layer handles addressing)
4. Server TCP Socket reassembles segments into original HTTP message
5. HTTP Parser extracts method, headers, body into structured data
6. Server routes request to your handler code based on method + path

Internal Mechanics: What's Actually on the Wire

GET /api/users/123 HTTP/1.1\r\n
Host: api.example.com\r\n
Accept: application/json\r\n
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7)\r\n
Accept-Encoding: gzip, deflate, br\r\n
Connection: keep-alive\r\n
\r\n

• \r\n is CRLF (Carriage Return + Line Feed) - required after EVERY line
• The blank line (\r\n\r\n) separates headers from body
• No body for GET requests
• Each header is Key: Value\r\n
• Request line format: METHOD URI VERSION\r\n

HTTP/1.1 200 OK\r\n
Date: Sun, 26 Jan 2026 15:30:00 GMT\r\n
Content-Type: application/json; charset=utf-8\r\n
Content-Length: 58\r\n
Cache-Control: max-age=300\r\n
ETag: "33a64df551425fcc55e"\r\n
Connection: keep-alive\r\n
\r\n
{"id":123,"name":"Alice","email":"alice@example.com"}

• Date: When response was generated (required by spec)
• Content-Type: Tells client how to parse the body
• Content-Length: Client knows when full body is received
• Cache-Control: How long this can be cached (300 seconds)
• ETag: Unique identifier for this version - used for conditional requests
• Connection: keep-alive: Keep TCP connection open

Protocol Specifications

• Host (REQUIRED): Virtual hosting - multiple domains on one IP

  Host: www.example.com

• Accept: Content negotiation - what formats client understands

  Accept: application/json, text/html;q=0.9, */*;q=0.8

  The q values (quality factors) indicate preference: 1.0 is highest (default)
• Authorization: Credentials for authentication

  Authorization: Bearer eyJhbGciOiJIUzI1NiIs...
  Authorization: Basic dXNlcjpwYXNzd29yZA==

• If-None-Match: Conditional request with ETag

  If-None-Match: "33a64df551425fcc55e"

  Server returns 304 if resource hasn't changed
• User-Agent: Client identification

  User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36

• Content-Type: MIME type of response body

  Content-Type: application/json; charset=utf-8
  Content-Type: text/html; charset=UTF-8
  Content-Type: image/png

• Cache-Control: Caching directives

  Cache-Control: max-age=3600           # Cache for 1 hour
  Cache-Control: no-cache              # Validate before using
  Cache-Control: no-store              # Never cache
  Cache-Control: public, max-age=31536000  # Cache 1 year, any cache

• Set-Cookie: Send cookie to client

    Set-Cookie:session=abc123;
    Path=/; HttpOnly;
    Secure;
    SameSite=Strict

• Location: Used with 3xx redirects and 201 Created

    Location: https://example.com/users/123
  

Code Deep Dive: Complete Examples

Example 1: HTTP Server in Go (Production-Ready)

go
package main

import (
    "encoding/json"
    "fmt"
    "log"
    "net/http"
    "strconv"
    "sync"
    "time"
)

// User represents our domain model
type User struct {
    ID    int    `json:"id"`
    Name  string `json:"name"`
    Email string `json:"email"`
}

// Simple in-memory store with mutex for concurrency safety
// WHY: HTTP servers handle multiple requests concurrently,
// so we need thread-safe data access
type UserStore struct {
    mu    sync.RWMutex
    users map[int]User
    nextID int
}

func NewUserStore() *UserStore {
    return &UserStore{
        users: make(map[int]User),
        nextID: 1,
    }
}

// Create adds a new user (POST /users)
// WHY return 201 Created: Signals successful resource creation
// WHY return Location header: Tells client where to find new resource
func (s *UserStore) Create(user User) (User, error) {
    s.mu.Lock()
    defer s.mu.Unlock()

    user.ID = s.nextID
    s.users[user.ID] = user
    s.nextID++

    return user, nil
}

// Get retrieves a user by ID (GET /users/{id})
// WHY use RLock: Multiple readers can access simultaneously (better performance)
// WHY separate lock types: Read operations don't block each other
func (s *UserStore) Get(id int) (User, bool) {
    s.mu.RLock()
    defer s.mu.RUnlock()

    user, exists := s.users[id]
    return user, exists
}

// GetAll returns all users (GET /users)
func (s *UserStore) GetAll() []User {
    s.mu.RLock()
    defer s.mu.RUnlock()

    users := make([]User, 0, len(s.users))
    for _, user := range s.users {
        users = append(users, user)
    }
    return users
}

// Update modifies existing user (PUT /users/{id})
func (s *UserStore) Update(id int, user User) bool {
    s.mu.Lock()
    defer s.mu.Unlock()

    if _, exists := s.users[id]; !exists {
        return false
    }

    user.ID = id
    s.users[id] = user
    return true
}

// Delete removes a user (DELETE /users/{id})
// WHY check existence: Return 404 if not found, not 204
func (s *UserStore) Delete(id int) bool {
    s.mu.Lock()
    defer s.mu.Unlock()

    if _, exists := s.users[id]; !exists {
        return false
    }

    delete(s.users, id)
    return true
}

// Middleware for logging every request
// WHY middleware: Separation of concerns - logging is cross-cutting
// WHY wrap handler: Allows us to execute code before AND after the handler
func loggingMiddleware(next http.HandlerFunc) http.HandlerFunc {
    return func(w http.ResponseWriter, r *http.Request) {
        start := time.Now()

        // Log request
        log.Printf("Started %s %s", r.Method, r.URL.Path)

        // Call the actual handler
        next(w, r)

        // Log response time
        log.Printf("Completed in %v", time.Since(start))
    }
}

// Set CORS headers for browser clients
// WHY CORS: Browsers enforce same-origin policy - this opts in to cross-origin
func setCORSHeaders(w http.ResponseWriter) {
    w.Header().Set("Access-Control-Allow-Origin", "*")
    w.Header().Set("Access-Control-Allow-Methods", "GET, POST, PUT, DELETE, OPTIONS")
    w.Header().Set("Access-Control-Allow-Headers", "Content-Type, Authorization")
}

func main() {
    store := NewUserStore()

    // Seed some data
    store.Create(User{Name: "Alice", Email: "alice@example.com"})
    store.Create(User{Name: "Bob", Email: "bob@example.com"})

    // Routes
    // WHY pattern matching: http.ServeMux uses longest match wins
    // WHY trailing slash matters: "/users/" matches /users/123, "/users" doesn't
    http.HandleFunc("/users", loggingMiddleware(func(w http.ResponseWriter, r *http.Request) {
        // WHY check method explicitly: Different methods = different operations
        // WHY not use switch: Each case is substantially different

        // Handle CORS preflight
        // WHY: Browsers send OPTIONS before actual request for cross-origin
        if r.Method == "OPTIONS" {
            setCORSHeaders(w)
            w.WriteHeader(http.StatusNoContent)
            return
        }

        setCORSHeaders(w)

        if r.Method == "GET" {
            // GET /users - List all users
            users := store.GetAll()

            // WHY set Content-Type: Client needs to know how to parse response
            w.Header().Set("Content-Type", "application/json")
            // WHY set Cache-Control: List can be cached for 30 seconds
            w.Header().Set("Cache-Control", "max-age=30")

            // WHY 200 OK: Successful retrieval (even if empty list)
            w.WriteHeader(http.StatusOK)
            json.NewEncoder(w).Encode(users)

        } else if r.Method == "POST" {
            // POST /users - Create new user
            var user User

            // WHY decode JSON: Request body is JSON string, need Go struct
            if err := json.NewDecoder(r.Body).Decode(&user); err != nil {
                // WHY 400 Bad Request: Client sent malformed data
                w.Header().Set("Content-Type", "application/json")
                w.WriteHeader(http.StatusBadRequest)
                json.NewEncoder(w).Encode(map[string]string{
                    "error": "Invalid JSON",
                })
                return
            }

            createdUser, _ := store.Create(user)

            // WHY set Location: RESTful practice - tell client where to find resource
            w.Header().Set("Location", fmt.Sprintf("/users/%d", createdUser.ID))
            w.Header().Set("Content-Type", "application/json")
            // WHY 201 Created: Specifically for successful resource creation
            w.WriteHeader(http.StatusCreated)
            json.NewEncoder(w).Encode(createdUser)

        } else {
            // WHY 405 Method Not Allowed: Method exists but not allowed on this resource
            // WHY not 404: Resource exists, method just isn't allowed
            w.Header().Set("Allow", "GET, POST, OPTIONS")
            w.WriteHeader(http.StatusMethodNotAllowed)
        }
    }))

    http.HandleFunc("/users/", loggingMiddleware(func(w http.ResponseWriter, r *http.Request) {
        // Extract ID from path: /users/123 -> 123
        // WHY manual parsing: Go's http.ServeMux doesn't support path parameters
        // (Modern alternatives: chi, gorilla/mux, httprouter)
        idStr := r.URL.Path[len("/users/"):]
        id, err := strconv.Atoi(idStr)
        if err != nil {
            w.WriteHeader(http.StatusBadRequest)
            return
        }

        if r.Method == "OPTIONS" {
            setCORSHeaders(w)
            w.WriteHeader(http.StatusNoContent)
            return
        }

        setCORSHeaders(w)

        if r.Method == "GET" {
            user, exists := store.Get(id)
            if !exists {
                // WHY 404 Not Found: Resource doesn't exist
                w.WriteHeader(http.StatusNotFound)
                return
            }

            w.Header().Set("Content-Type", "application/json")
            // WHY longer cache: Individual resources change less frequently
            w.Header().Set("Cache-Control", "max-age=300")
            // WHY ETag: Enables conditional requests with If-None-Match
            w.Header().Set("ETag", fmt.Sprintf(`"%d-v1"`, user.ID))

            w.WriteHeader(http.StatusOK)
            json.NewEncoder(w).Encode(user)

        } else if r.Method == "PUT" {
            var user User
            if err := json.NewDecoder(r.Body).Decode(&user); err != nil {
                w.WriteHeader(http.StatusBadRequest)
                return
            }

            if store.Update(id, user) {
                w.Header().Set("Content-Type", "application/json")
                w.WriteHeader(http.StatusOK)
                json.NewEncoder(w).Encode(user)
            } else {
                // WHY 404: Can't update what doesn't exist
                // Alternative: Create it (then return 201 Created)
                w.WriteHeader(http.StatusNotFound)
            }

        } else if r.Method == "DELETE" {
            if store.Delete(id) {
                // WHY 204 No Content: Success but nothing to return
                // Alternative: Return deleted resource with 200 OK
                w.WriteHeader(http.StatusNoContent)
            } else {
                w.WriteHeader(http.StatusNotFound)
            }

        } else {
            w.Header().Set("Allow", "GET, PUT, DELETE, OPTIONS")
            w.WriteHeader(http.StatusMethodNotAllowed)
        }
    }))

    // WHY port 8080: Common dev port, doesn't require root (ports < 1024 do)
    log.Println("Server starting on http://localhost:8080")

    // WHY ListenAndServe: Blocking call that accepts connections forever
    // Under the hood: Creates TCP listener, spawns goroutine per connection
    if err := http.ListenAndServe(":8080", nil); err != nil {
        log.Fatal(err)
    }
}

1. TCP Connection: Go's HTTP server accepts TCP connection
2. Goroutine Spawned: Each connection handled by separate goroutine (lightweight thread)
3. HTTP Parsing: Server reads from socket, parses HTTP request line-by-line
4. Routing: ServeMux matches URL path to registered handler
5. Handler Execution: Your code runs, has access to Request and ResponseWriter
6. Response Writing: Data written to ResponseWriter buffers, then flushes to TCP socket
7. Connection Management: If Connection: keep-alive, socket stays open for next request

Example 2: HTTP Client in Python (Advanced Usage)

python
import requests
from requests.adapters import HTTPAdapter
from urllib3.util.retry import Retry
import json
import time

class APIClient:
    """
    Production-ready HTTP client with connection pooling,
    retries, and timeout handling.

    WHY use Session: Reuses TCP connections (connection pooling)
    WHY use mount: Applies retry strategy to all requests
    WHY custom timeouts: Prevent hanging on slow servers
    """

    def __init__(self, base_url, timeout=10):
        self.base_url = base_url
        self.timeout = timeout
        self.session = requests.Session()

        # Configure retry strategy
        # WHY retry on these status codes: They're often transient errors
        # WHY backoff_factor: 1s, 2s, 4s, 8s delays prevent hammering
        retry_strategy = Retry(
            total=3,  # Total number of retries
            backoff_factor=1,  # Exponential backoff
            status_forcelist=[429, 500, 502, 503, 504],
            allowed_methods=["HEAD", "GET", "OPTIONS", "PUT", "DELETE"]
            # WHY not POST: POST isn't idempotent - retrying could duplicate
        )

        adapter = HTTPAdapter(
            max_retries=retry_strategy,
            pool_connections=10,  # Number of connection pools
            pool_maxsize=20       # Max connections per pool
        )

        # WHY mount for both http and https: Cover all bases
        self.session.mount("http://", adapter)
        self.session.mount("https://", adapter)

        # Set default headers for all requests
        # WHY User-Agent: Good practice, some servers require it
        self.session.headers.update({
            'User-Agent': 'APIClient/1.0',
            'Accept': 'application/json'
        })

    def get(self, endpoint, params=None, use_cache=True):
        """
        GET request with optional caching support.

        WHY params separate: requests library URL-encodes them properly
        WHY use_cache parameter: Sometimes you need fresh data
        """
        url = f"{self.base_url}{endpoint}"

        headers = {}
        if not use_cache:
            # WHY Cache-Control in request: Tell intermediary caches to fetch fresh
            # WHY Pragma: HTTP/1.0 backward compatibility
            headers['Cache-Control'] = 'no-cache'
            headers['Pragma'] = 'no-cache'

        try:
            response = self.session.get(
                url,
                params=params,
                headers=headers,
                timeout=self.timeout  # (connect timeout, read timeout)
            )

            # WHY raise_for_status: Converts 4xx/5xx to exceptions
            # Makes error handling consistent
            response.raise_for_status()

            # Log cache status
            # WHY check X-Cache: See if CDN served cached response
            if 'X-Cache' in response.headers:
                print(f"Cache: {response.headers['X-Cache']}")

            return response.json()

        except requests.exceptions.Timeout:
            # WHY separate exception types: Different recovery strategies
            print(f"Request to {url} timed out")
            raise
        except requests.exceptions.ConnectionError:
            print(f"Failed to connect to {url}")
            raise
        except requests.exceptions.HTTPError as e:
            print(f"HTTP error: {e.response.status_code}")
            raise

    def post(self, endpoint, data=None, json_data=None):
        """
        POST request for creating resources.

        WHY data vs json_data parameters: Different content types
        - data: application/x-www-form-urlencoded
        - json_data: application/json
        """
        url = f"{self.base_url}{endpoint}"

        # WHY choose json over data: Modern APIs prefer JSON
        # requests library automatically sets Content-Type: application/json
        response = self.session.post(
            url,
            json=json_data if json_data else None,
            data=data if data else None,
            timeout=self.timeout
        )

        response.raise_for_status()

        # WHY check Location header: Server tells us where resource was created
        if 'Location' in response.headers:
            print(f"Resource created at: {response.headers['Location']}")

        # WHY check status code: 201 vs 200 tells us about server behavior
        if response.status_code == 201:
            return response.json()
        else:
            # Some servers return 200 OK instead of 201 Created
            return response.json() if response.content else None

    def put(self, endpoint, json_data):
        """
        PUT request for full replacement updates.

        WHY PUT not PATCH: PUT replaces entire resource
        MUST send complete object, not partial fields
        """
        url = f"{self.base_url}{endpoint}"
        response = self.session.put(url, json=json_data, timeout=self.timeout)
        response.raise_for_status()
        return response.json()

    def patch(self, endpoint, json_data):
        """
        PATCH request for partial updates.

        WHY PATCH: Only send changed fields, more bandwidth-efficient
        Server merges changes with existing resource
        """
        url = f"{self.base_url}{endpoint}"
        response = self.session.patch(url, json=json_data, timeout=self.timeout)
        response.raise_for_status()
        return response.json()

    def delete(self, endpoint):
        """
        DELETE request for removing resources.

        WHY check 204 No Content: Server might not return body
        """
        url = f"{self.base_url}{endpoint}"
        response = self.session.delete(url, timeout=self.timeout)
        response.raise_for_status()

        # WHY 204 check: Avoid parsing empty response as JSON
        if response.status_code == 204:
            return None
        return response.json() if response.content else None

    def conditional_get(self, endpoint, etag=None, last_modified=None):
        """
        Conditional GET using ETag or Last-Modified.

        WHY conditional requests: Save bandwidth, reduce server load
        Server returns 304 Not Modified if resource unchanged
        """
        url = f"{self.base_url}{endpoint}"
        headers = {}

        if etag:
            # WHY If-None-Match: "Give me resource unless ETag matches"
            headers['If-None-Match'] = etag

        if last_modified:
            # WHY If-Modified-Since: "Give me resource only if changed since date"
            headers['If-Modified-Since'] = last_modified

        response = self.session.get(url, headers=headers, timeout=self.timeout)

        # WHY check 304: Resource hasn't changed, use cached version
        if response.status_code == 304:
            print("Resource not modified, use cached version")
            return None  # Signal to use cache

        response.raise_for_status()

        # Return new data along with cache validators
        return {
            'data': response.json(),
            'etag': response.headers.get('ETag'),
            'last_modified': response.headers.get('Last-Modified')
        }

    def close(self):
        """Close session and cleanup connection pool."""
        self.session.close()

# Usage example demonstrating all features
if __name__ == "__main__":
    client = APIClient("http://localhost:8080")

    try:
        # Create a new user (POST)
        print("Creating user...")
        new_user = client.post("/users", json_data={
            "name": "Charlie",
            "email": "charlie@example.com"
        })
        print(f"Created: {new_user}")

        # Get all users (GET)
        print("\nFetching all users...")
        users = client.get("/users")
        print(f"Users: {users}")

        # Get specific user (GET)
        print("\nFetching user by ID...")
        user = client.get(f"/users/{new_user['id']}")
        print(f"User: {user}")

        # Conditional GET example
        print("\nConditional GET example...")
        result = client.conditional_get(
            f"/users/{new_user['id']}",
            etag=f'"{new_user["id"]}-v1"'
        )
        if result:
            print(f"Resource changed: {result['data']}")
            # Store ETag for next time
            etag = result['etag']
        else:
            print("Resource unchanged")

        # Partial update (PATCH)
        print("\nPartially updating user...")
        updated = client.patch(f"/users/{new_user['id']}", json_data={
            "name": "Charles"  # Only updating name
        })
        print(f"Updated: {updated}")

        # Full replacement (PUT)
        print("\nFully replacing user...")
        replaced = client.put(f"/users/{new_user['id']}", json_data={
            "name": "Chuck",
            "email": "chuck@example.com"
        })
        print(f"Replaced: {replaced}")

        # Delete user (DELETE)
        print("\nDeleting user...")
        client.delete(f"/users/{new_user['id']}")
        print("Deleted successfully")

        # Verify deletion
        try:
            client.get(f"/users/{new_user['id']}")
        except requests.exceptions.HTTPError as e:
            if e.response.status_code == 404:
                print("Confirmed: User no longer exists")

    finally:
        # WHY finally block: Ensure connections cleaned up even on error
        client.close()

1. Session Creation: Creates connection pool (reusable TCP connections)
2. First Request: DNS lookup → TCP handshake → HTTP request
3. Connection Pooling: TCP connection stored in pool (key: host+port)
4. Subsequent Requests: Reuse existing connection from pool (skip DNS + TCP)
5. Retry Logic: On failure, adapter automatically retries with backoff
6. Timeout Handling: Separate connect vs read timeouts prevent indefinite hangs

Example 3: Raw HTTP with JavaScript (Understanding the Fundamentals)

javascript
/**
 * Low-level HTTP demonstration using Node.js 'net' module
 * Shows exactly what goes over the wire
 *
 * WHY use 'net' instead of 'http' module: See raw TCP communication
 * WHY this matters: Debugging network issues requires understanding bytes on wire
 */

const net = require('net');

function sendRawHTTPRequest(host, port, method, path, headers = {}, body = null) {
    return new Promise((resolve, reject) => {
        // Create TCP socket connection
        // WHY net.createConnection: Direct TCP socket, no HTTP abstraction
        const socket = net.createConnection({ host, port }, () => {
            console.log('TCP connection established');

            // Build HTTP request manually
            // WHY \r\n: HTTP spec requires CRLF (Carriage Return + Line Feed)
            let request = `${method} ${path} HTTP/1.1\r\n`;

            // Host header is REQUIRED in HTTP/1.1
            // WHY required: Virtual hosting - multiple domains on one IP
            request += `Host: ${host}\r\n`;

            // Add custom headers
            for (const [key, value] of Object.entries(headers)) {
                request += `${key}: ${value}\r\n`;
            }

            // If body exists, set Content-Length
            // WHY Content-Length required: Server needs to know when body ends
            if (body) {
                const bodyBytes = Buffer.byteLength(body, 'utf8');
                request += `Content-Length: ${bodyBytes}\r\n`;
                request += `Content-Type: application/json\r\n`;
            }

            // Add Connection header for explicit control
            // WHY keep-alive: Reuse connection for subsequent requests
            request += `Connection: keep-alive\r\n`;

            // Blank line separates headers from body
            // WHY \r\n\r\n: Two CRLFs signal end of headers
            request += `\r\n`;

            // Add body if present
            if (body) {
                request += body;
            }

            console.log('\n📤 Sending raw HTTP request:\n---');
            // Show non-printable characters
            console.log(request.replace(/\r\n/g, '\\r\\n\n'));
            console.log('---\n');

            // Send the raw bytes
            socket.write(request);
        });

        let responseData = '';

        // WHY 'data' event: TCP sends chunks, not complete messages
        // HTTP response might arrive in multiple TCP segments
        socket.on('data', (chunk) => {
            responseData += chunk.toString();

            // WHY check for \r\n\r\n: Marks end of headers
            // Body size determined by Content-Length or chunked encoding
            if (responseData.includes('\r\n\r\n')) {
                const [headers, body] = responseData.split('\r\n\r\n', 2);

                // Parse status line
                const lines = headers.split('\r\n');
                const statusLine = lines[0];
                const [version, statusCode, ...reasonParts] = statusLine.split(' ');
                const reasonPhrase = reasonParts.join(' ');

                console.log('📥 Received raw HTTP response:\n---');
                console.log(`Status: ${statusCode} ${reasonPhrase}`);
                console.log('\nHeaders:');

                const headerMap = {};
                for (let i = 1; i < lines.length; i++) {
                    const [key, ...valueParts] = lines[i].split(': ');
                    const value = valueParts.join(': ');
                    headerMap[key.toLowerCase()] = value;
                    console.log(`  ${key}: ${value}`);
                }

                console.log('\nBody:');
                console.log(body || '(empty)');
                console.log('---\n');

                // Check if we should close connection
                // WHY check Connection header: Determines connection persistence
                const connectionHeader = headerMap['connection'];
                if (connectionHeader && connectionHeader.toLowerCase() === 'close') {
                    socket.end();
                }

                resolve({
                    statusCode: parseInt(statusCode),
                    reasonPhrase,
                    headers: headerMap,
                    body
                });
            }
        });

        socket.on('error', (err) => {
            console.error('Socket error:', err.message);
            reject(err);
        });

        socket.on('end', () => {
            console.log('🔌 Connection closed by server');
        });
    });
}

// Demonstration of different HTTP methods
async function demo() {
    const host = 'localhost';
    const port = 8080;

    try {
        // GET request
        console.log('=== GET Request ===\n');
        await sendRawHTTPRequest(host, port, 'GET', '/users', {
            'Accept': 'application/json',
            'User-Agent': 'RawHTTPClient/1.0'
        });

        await new Promise(resolve => setTimeout(resolve, 1000));

        // POST request
        console.log('\n=== POST Request ===\n');
        const userData = JSON.stringify({
            name: 'David',
            email: 'david@example.com'
        });

        await sendRawHTTPRequest(host, port, 'POST', '/users', {
            'Accept': 'application/json',
            'User-Agent': 'RawHTTPClient/1.0'
        }, userData);

    } catch (error) {
        console.error('Demo failed:', error);
    }
}

// Run demonstration
demo();

[Application Layer - HTTP]
    ↓
    Your code builds text: "GET /users HTTP/1.1\r\nHost: localhost\r\n..."
    ↓
[Transport Layer - TCP]
    ↓
    TCP breaks text into segments, adds:
    - Source/Destination ports (8080)
    - Sequence numbers
    - Checksum
    ↓
[Network Layer - IP]
    ↓
    IP adds routing information:
    - Source/Destination IP addresses
    - TTL, Protocol (TCP = 6)
    ↓
[Link Layer - Ethernet]
    ↓
    Adds MAC addresses, sends bits over wire

Benefits & Why It Matters

Performance Benefits

• HTTP/1.0: Each request = new TCP connection = 100ms overhead
• HTTP/1.1 keep-alive: One connection for multiple requests = ~50% latency reduction

• HTTP/1.0: 50 connections × 100ms = 5,000ms (5 seconds) just for handshakes
• HTTP/1.1: 1 connection × 100ms = 100ms, then pipelined requests

• Properly implemented caching can reduce server load by 70-90%
• ETag/Last-Modified enable smart revalidation without full downloads
• Cache-Control: max-age=31536000
  for immutable resources (CSS with hash filenames) = instant loads

Diagram 9

Developer Experience

• Text-based protocol means you can read it with curl, tcpdump, or browser DevTools
• Try:
  curl -v https://api.github.com/users/octocat
• The -v flag shows exact HTTP headers sent and received

• Every language has robust HTTP libraries
• RESTful APIs built on HTTP are universally understood
• Tooling (Postman, Insomnia, httpie) work across platforms

• Headers are extensible - add custom headers like X-Request-ID for tracing
• Content negotiation allows same endpoint to serve JSON, XML, HTML
• Authentication methods (Bearer, Basic, Digest) plug in via headers

Real-World Success Stories

• GitHub API: Serves billions of requests using HTTP/1.1 REST principles
• Stripe API: Built on HTTP/1.1, handles millions in transactions with 99.99% uptime
• Netflix: Initially HTTP/1.1 (now HTTP/2), but principles remain the same

Trade-offs & Gotchas

When to Use HTTP/1.1

• RESTful APIs with moderate request rates
• Server-to-server communication
• Simple CRUD applications
• When broad compatibility is critical
• Debugging (human-readable protocol)
• Learning web fundamentals

• Internal microservices (simplicity > performance)
• Webhooks (one-off requests, no connection reuse benefit)
• IoT devices (lightweight, simple parsing)

When NOT to Use

• Real-time apps (chat, gaming): Use WebSockets or HTTP/2 Server Push
• High-frequency trading: HTTP/1.1 overhead too high, use binary protocols (gRPC, custom TCP)
• Streaming media: HTTP/1.1 works but HTTP/2 or RTMP better suited
• Mobile apps on slow networks: HTTP/2 or HTTP/3 (QUIC) reduce latency significantly

• HTTP/2: Multiplexing eliminates head-of-line blocking, binary format is more efficient
• WebSockets: Full-duplex, persistent connection for bidirectional communication
• gRPC: HTTP/2-based, Protobuf binary serialization, ~7x faster than JSON

Common Mistakes

1. Not reusing connections (connection pool exhaustion)

python
# BAD: Creates new connection every time
for i in range(1000):
    response = requests.get('https://api.example.com/data')

# GOOD: Reuses connection pool
session = requests.Session()
for i in range(1000):
    response = session.get('https://api.example.com/data')

2. Misusing PUT vs PATCH vs POST

javascript
// BAD: Using POST for updates
POST /users/123 { "name": "New Name" }

// BAD: Using PUT for partial updates (overwrites other fields!)
PUT /users/123 { "name": "New Name" }
// Result: email, phone, etc. all become null!

// GOOD: Use PATCH for partial updates
PATCH /users/123 { "name": "New Name" }

// GOOD: Use PUT only when sending complete resource
PUT /users/123 { "id": 123, "name": "New Name", "email": "user@example.com", ... }

3. Ignoring status codes (treating all responses as success)

go
// BAD: Not checking status
resp, _ := http.Get("https://api.example.com/data")
json.NewDecoder(resp.Body).Decode(&data) // Panics on 404!

// GOOD: Check status and handle errors
resp, err := http.Get("https://api.example.com/data")
if err != nil {
    return err
}
defer resp.Body.Close()

if resp.StatusCode != http.StatusOK {
    body, _ := io.ReadAll(resp.Body)
    return fmt.Errorf("API error %d: %s", resp.StatusCode, body)
}

json.NewDecoder(resp.Body).Decode(&data)

4. Not setting timeouts (hanging forever)

python
# BAD: No timeout - hangs indefinitely if server doesn't respond
response = requests.get('https://slow-server.com')

# GOOD: Set reasonable timeout
response = requests.get('https://slow-server.com', timeout=10)

# BETTER: Separate connect vs read timeout
response = requests.get('https://slow-server.com', timeout=(3, 10))
# 3s to connect, 10s to read response

5. Cache headers misconfiguration

http
# BAD: Caching dynamic data
Cache-Control: max-age=86400
Content: {"balance": "$1,234.56"}
# User's balance cached for 24 hours!

# GOOD: No caching for dynamic data
Cache-Control: no-cache, no-store, must-revalidate
Pragma: no-cache
Expires: 0

# GOOD: Aggressive caching for static assets
Cache-Control: public, max-age=31536000, immutable
Content: style.a8d9c2b7.css

6. Not closing response bodies (resource leak)

go
// BAD: Response body never closed - leaks TCP connections
resp, _ := http.Get("https://api.example.com/data")
json.NewDecoder(resp.Body).Decode(&data)

// GOOD: Always defer close
resp, err := http.Get("https://api.example.com/data")
if err != nil {
    return err
}
defer resp.Body.Close() // Cleanup even if function panics

json.NewDecoder(resp.Body).Decode(&data)

7. Sending wrong Content-Type

javascript
// BAD: Sending JSON without Content-Type
fetch('/api/users', {
    method: 'POST',
    body: JSON.stringify({ name: 'Alice' })
    // Server receives it as text/plain or form data!
});

// GOOD: Explicit Content-Type
fetch('/api/users', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ name: 'Alice' })
});

8. Retry logic on non-idempotent methods

python
# BAD: Retrying POST can create duplicate resources
response = requests.post('/api/orders', json=order_data,
                         retries=3)  # Might create 3 orders!

# GOOD: Only retry idempotent methods
retry_strategy = Retry(
    total=3,
    allowed_methods=["HEAD", "GET", "OPTIONS", "PUT", "DELETE"]
    # POST excluded
)

Performance Considerations

• HTTP/1.1 is synchronous - must wait for response before next request
• Workaround: Open multiple connections (browsers use 6 per domain)
• Better solution: Upgrade to HTTP/2 for multiplexing

• Headers sent with EVERY request - cookies can be 4KB+
• Impact: 4KB × 100 requests = 400KB overhead
• Fix: Use separate domain for static assets (no cookies sent)

• Text data (JSON, HTML) can be 10x larger uncompressed
• Fix: Enable gzip/brotli compression (Accept-Encoding: gzip, br)
• Check:
  curl -H "Accept-Encoding: gzip" -I https://example.com

• Enable keep-alive (it's default in HTTP/1.1)
• Use compression (gzip for text, brotli for modern browsers)
• Implement caching with ETags/Last-Modified
• Use connection pooling in clients
• Set appropriate cache headers (immutable for hashed assets)
• Consider HTTP/2 if you control both client and server

Security Considerations

http
# NEVER: Credentials logged in server access logs
GET /api/data?api_key=secret123

# Use headers instead
GET /api/data
Authorization: Bearer secret123

http
# DANGEROUS: Allows any origin
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true

# Whitelist specific origins
Access-Control-Allow-Origin: https://trusted-app.com

http
# Essential security headers
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
Content-Security-Policy: default-src 'self'

http
# BAD: Cookie can be stolen by JavaScript or sent over HTTP
Set-Cookie: session=abc123

# GOOD: Secure, HttpOnly, SameSite
Set-Cookie: session=abc123; Secure; HttpOnly; SameSite=Strict; Path=/

http
# BAD: Password in URL (logged everywhere)
GET /login?username=alice&password=secret123

# GOOD: POST with body
POST /login
Content-Type: application/json

{"username":"alice","password":"secret123"}

Comparison with Alternatives

Hands-On Examples

Scenario 1: Building a RESTful API Client with Caching

javascript
class CachedAPIClient {
    constructor(baseURL) {
        this.baseURL = baseURL;
        this.cache = new Map(); // Simple in-memory cache
    }

    /**
     * Smart GET with caching and conditional requests
     *
     * Flow:
     * 1. Check local cache
     * 2. If cached, send conditional request with ETag
     * 3. If 304 Not Modified, use cached version
     * 4. If 200 OK, update cache with new data
     */
    async get(endpoint) {
        const url = `${this.baseURL}${endpoint}`;
        const cached = this.cache.get(url);

        const headers = {
            'Accept': 'application/json'
        };

        // If we have cached data, send conditional request
        // WHY: Save bandwidth - server returns 304 if unchanged
        if (cached && cached.etag) {
            headers['If-None-Match'] = cached.etag;
            console.log(`🔄 Sending conditional request with ETag: ${cached.etag}`);
        }

        const response = await fetch(url, { headers });

        // Check if resource hasn't changed
        // WHY 304: Server validated our cached version is still current
        if (response.status === 304) {
            console.log('Cache hit! Using cached data.');
            return cached.data;
        }

        // Resource changed or first request
        if (response.ok) {
            const data = await response.json();
            const etag = response.headers.get('ETag');
            const cacheControl = response.headers.get('Cache-Control');

            console.log(`📥 Received new data. ETag: ${etag}`);
            console.log(`📋 Cache-Control: ${cacheControl}`);

            // Parse Cache-Control to determine if we should cache
            // WHY check Cache-Control: Respect server's caching policy
            if (cacheControl && !cacheControl.includes('no-store')) {
                // Extract max-age if present
                const maxAgeMatch = cacheControl.match(/max-age=(\d+)/);
                const maxAge = maxAgeMatch ? parseInt(maxAgeMatch[1]) : null;

                // Store in cache with metadata
                this.cache.set(url, {
                    data,
                    etag,
                    cachedAt: Date.now(),
                    maxAge: maxAge ? maxAge * 1000 : null // Convert to ms
                });

                console.log(`💾 Cached for ${maxAge} seconds`);
            }

            return data;
        }

        throw new Error(`HTTP ${response.status}: ${response.statusText}`);
    }

    /**
     * Check if cached data is still fresh based on max-age
     * WHY: Avoid unnecessary network requests for fresh data
     */
    isCacheFresh(url) {
        const cached = this.cache.get(url);
        if (!cached || !cached.maxAge) return false;

        const age = Date.now() - cached.cachedAt;
        return age < cached.maxAge;
    }

    /**
     * Demonstrate cache behavior
     */
    async demo() {
        const endpoint = '/users/1';

        console.log('=== First Request (cache miss) ===');
        await this.get(endpoint);

        console.log('\n=== Second Request (conditional) ===');
        await this.get(endpoint);

        console.log('\n=== Third Request (still cached) ===');
        await this.get(endpoint);
    }
}

// Usage
const client = new CachedAPIClient('http://localhost:8080');
client.demo();

=== First Request (cache miss) ===
📥 Received new data. ETag: "1-v1"
📋 Cache-Control: max-age=300
💾 Cached for 300 seconds

=== Second Request (conditional) ===
🔄 Sending conditional request with ETag: "1-v1"
Cache hit! Using cached data.

=== Third Request (still cached) ===
🔄 Sending conditional request with ETag: "1-v1"
Cache hit! Using cached data.

1. Start the Go server from earlier examples
2. Run this client multiple times
3. Watch the server logs - second request still hits server but returns 304
4. Modify the user data - next request returns 200 with new data

Scenario 2: Debugging HTTP Issues with curl

bash
# 1. See full request/response headers
curl -v https://api.github.com/users/octocat

# 2. Test API endpoint with JSON POST
curl -X POST http://localhost:8080/users \
  -H "Content-Type: application/json" \
  -d '{"name":"Eve","email":"eve@example.com"}' \
  -v

# 3. Test conditional GET with ETag
curl -H "If-None-Match: \"1-v1\"" \
  http://localhost:8080/users/1 \
  -v

# 4. Test compression
curl -H "Accept-Encoding: gzip" \
  https://example.com \
  --compressed \
  -v

# 5. Test caching behavior
curl -H "Cache-Control: no-cache" \
  http://localhost:8080/users \
  -v

# 6. Follow redirects
curl -L https://github.com

# 7. Save response headers to file
curl -D headers.txt https://api.github.com

# 8. Test timeout behavior
curl --max-time 5 https://slow-server.com

# 9. Test with specific HTTP version
curl --http1.1 https://example.com

# 10. See timing breakdown
curl -w "@curl-format.txt" -o /dev/null -s https://example.com

    time_namelookup:  %{time_namelookup}s\n
       time_connect:  %{time_connect}s\n
    time_appconnect:  %{time_appconnect}s\n
   time_pretransfer:  %{time_pretransfer}s\n
      time_redirect:  %{time_redirect}s\n
 time_starttransfer:  %{time_starttransfer}s\n
                    ----------\n
         time_total:  %{time_total}s\n

Interview Preparation

Q1: Explain the HTTP request-response lifecycle in detail.

1. DNS Resolution: Browser resolves domain to IP address (cached by OS/browser)
2. TCP Connection: Three-way handshake (SYN, SYN-ACK, ACK) establishes connection
3. TLS Handshake (if HTTPS): Client/server negotiate encryption (adds 1-2 RTT)
4. HTTP Request: Client sends text-based request (method, headers, body)
   • Request line: GET /path HTTP/1.1
   • Headers: Host:, Accept:, etc.
   • Blank line separates headers from body
5. Server Processing: Routes request, executes business logic, queries database
6. HTTP Response: Server sends status line, headers, body
   • Status line: HTTP/1.1 200 OK
   • Headers: Content-Type:, Cache-Control:, etc.
   • Body: The actual data
7. Connection Decision: Based on Connection header
   • keep-alive: Connection pooled for reuse
   • close: TCP teardown (FIN, FIN-ACK, ACK)

Q2: What's the difference between PUT, POST, and PATCH?

http
# POST: Server assigns ID, returns 201 Created with Location header
POST /users
Body: {"name":"Alice","email":"alice@example.com"}
Response: 201 Created, Location: /users/123

# PUT: Client specifies ID, must send all fields
PUT /users/123
Body: {"id":123,"name":"Alice","email":"alice@example.com","phone":"555-0100"}
Response: 200 OK (or 201 Created if didn't exist)

# PATCH: Only changed fields
PATCH /users/123
Body: {"email":"newemail@example.com"}
Response: 200 OK

• PUT /users/123 with same body = same result every time (safe to retry)
• POST /users with same body = creates duplicate users (DON'T auto-retry)
• PATCH depends on implementation ({"age": 30} is idempotent, {"age": "+1"} isn't)

Q3: How does HTTP caching work? Explain ETags vs Last-Modified.

• max-age=3600: Fresh for 1 hour, don't contact server
• no-cache: Contact server before using (validate with 304)
• no-store: Never cache (sensitive data)
• public: Any cache (CDN, proxy) can store
• private: Only browser cache, not shared caches

• Unique identifier for specific version (like a hash)
• Server generates based on content: ETag: "33a64df551"
• Client sends back: If-None-Match: "33a64df551"
• Server returns 304 if unchanged, 200 with new data if changed

• Timestamp of last modification:
  Last-Modified: Wed, 21 Oct 2015 07:28:00 GMT
• Client sends back:
  If-Modified-Since: Wed, 21 Oct 2015 07:28:00 GMT
• Server returns 304 if not modified since that date

• Content-based (detects changes even if timestamp same)
• Works when system clock skewed
• Supports weak ETags (W/"123") for functionally equivalent content

1. First request:
   Client → Server: GET /style.css
   Server → Client: 200 OK, ETag: "abc123", Cache-Control: max-age=300

2. Within 5 minutes (fresh):
   Client uses cached version, no network request

3. After 5 minutes (stale):
   Client → Server: GET /style.css, If-None-Match: "abc123"
   Server → Client: 304 Not Modified (or 200 with new content if changed)

Q4: What happens when you type a URL into a browser and press Enter?

1. URL Parsing: Browser parses

   https://example.com/path?query=value#hash
   • Protocol: HTTPS
   • Host: example.com
   • Port: 443 (default for HTTPS)
   • Path: /path
   • Query: query=value
2. Cache Check: Browser checks if resource cached and fresh
   • If fresh (max-age not expired), use cache
   • If stale, proceed but may send conditional request
3. DNS Resolution:
   • Check browser cache → OS cache → router cache → ISP DNS → root DNS → TLD DNS → authoritative DNS
   • Returns IP: 93.184.216.34
4. TCP Connection: Three-way handshake to port 443
5. TLS Handshake:
   • Client Hello (supported ciphers)
   • Server Hello (chosen cipher, certificate)
   • Key exchange and verification
   • Encrypted tunnel established
6. HTTP Request:

   GET /path?query=value HTTP/1.1
   Host: example.com
   User-Agent: Mozilla/5.0...
   Accept: text/html,application/xhtml+xml...
   Accept-Language: en-US,en;q=0.9
   Accept-Encoding: gzip, deflate, br
   Connection: keep-alive
   Cookie: session=abc123

7. Server Processing:
   • Web server (nginx) receives request
   • Routes to application server (Node/Python/Go)
   • Application executes logic, queries database
   • Generates response
8. HTTP Response:

   HTTP/1.1 200 OK
   Content-Type: text/html; charset=UTF-8
   Content-Encoding: gzip
   Cache-Control: max-age=3600
   Set-Cookie: session=xyz789; HttpOnly; Secure
   Content-Length: 4521
   
   <!DOCTYPE html><html>...

9. Browser Rendering:
   • Parse HTML → construct DOM tree
   • Parse CSS → construct CSSOM tree
   • Combine into render tree
   • Layout (calculate positions)
   • Paint (draw pixels)
   • Composite (handle layers)
10. Subresource Loading:
    • Find linked resources (CSS, JS, images)
    • Reuse TCP connection (keep-alive)
    • Parallel requests (6 per domain in HTTP/1.1)
    • Parse and execute JavaScript
    • Fetch API calls for dynamic data

Q5: How would you debug an API returning inconsistent responses?

bash
# Make multiple identical requests, save responses
for i in {1..10}; do
  curl -H "Accept: application/json" \
    https://api.example.com/users/123 \
    -o "response_$i.json"
  diff response_1.json response_$i.json
done

• Browser cache: Disable in DevTools (check "Disable cache")
• CDN cache: Check X-Cache or CF-Cache-Status headers
• Server-side cache: Redis, Memcached key inspection
• Test with cache-busting: ?nocache=<timestamp>

bash
curl -v https://api.example.com/users/123 2>&1 | tee http_debug.txt

• Vary header (response varies by certain headers)
• Set-Cookie (state changes between requests)
• Age header (how long cached)
• Different response headers between calls

bash
# Different servers might have different data
curl -v https://api.example.com/health
# Look for X-Server-ID, X-Node, or similar headers

# Force to specific server (if you control DNS)
curl --resolve api.example.com:443:10.0.1.5 https://api.example.com/users/123

• Check if reads hitting read replica
• Test against primary:
  curl https://api-primary.example.com/users/123
• Look for X-Database-Lag or similar headers

bash
# Parallel requests with same timestamp
time (
  curl https://api.example.com/users/123 &
  curl https://api.example.com/users/123 &
  wait
)

• Check response timestamps: Date header
• Test at different times of day
• Look for TTL-based caching or session expiration

bash
# Capture actual packets
sudo tcpdump -i any -s 0 -A 'tcp port 443 and host api.example.com'

# Or use Wireshark for GUI analysis

• Stale cache (browser, CDN, server)
• Multiple backend servers with inconsistent data
• Database replication lag
• A/B testing or feature flags
• Session-dependent responses without proper Vary headers
• Time-based logic (rate limiting, scheduled tasks)
• Race conditions in concurrent requests

Q6: Explain HTTP/1.1 persistent connections and head-of-line blocking.

• Each request = new TCP connection
• Overhead: DNS lookup + 3-way handshake + TLS handshake + slow start
• 50 resources = 50 connections = ~5 seconds just for handshakes

Connection: keep-alive

• One TCP connection serves multiple requests
• Connection stays open for ~60-120 seconds of inactivity
• Massive latency reduction (50-60%)

bash
# HTTP/1.0 style (close after each request)
curl -H "Connection: close" http://example.com

# HTTP/1.1 style (reuse connection)
curl -K - <<EOF
url = http://example.com/page1
url = http://example.com/page2
url = http://example.com/page3
EOF
# All three requests use same TCP connection

Client → Server: GET /large-file.mp4 (takes 10 seconds)
[BLOCKED: Can't send next request until large-file.mp4 completes]
Client wants: GET /style.css
Client wants: GET /script.js
[Waiting... waiting... waiting...]
Server → Client: large-file.mp4 (finally!)
Client → Server: GET /style.css

1. Multiple connections: Browsers open 6 concurrent connections per domain
   • Pros: Parallelism
   • Cons: TCP overhead, connection pool limits, server resource usage
2. Domain sharding: static1.example.com, static2.example.com
   • Pros: More parallel connections (6 × N domains)
   • Cons: Extra DNS lookups, breaks connection reuse, more TLS handshakes
3. Pipelining (rarely used):

   Client → Server: GET /file1
   Client → Server: GET /file2 (without waiting for file1 response)
   Client → Server: GET /file3
   Server → Client: file1
   Server → Client: file2
   Server → Client: file3 (must be in order!)

   • Pros: Reduces latency
   • Cons: Still blocks on slow responses, proxies break it, disabled by default in browsers

• Stream multiplexing: Multiple requests/responses on one connection simultaneously
• Each request gets stream ID, responses can arrive in any order
• No head-of-line blocking at HTTP layer (still exists at TCP layer)

Client → Server: Stream 1: GET /large-file.mp4
Client → Server: Stream 2: GET /style.css
Client → Server: Stream 3: GET /script.js
Server → Client: Stream 2: style.css (arrives first!)
Server → Client: Stream 3: script.js
Server → Client: Stream 1: large-file.mp4 (arrives last)

Quick Reference Sheet

• 200 OK - Success
• 201 Created - Resource created (POST)
• 204 No Content - Success, no body (DELETE)
• 301 Moved Permanently - Permanent redirect (update bookmarks)
• 302 Found - Temporary redirect
• 304 Not Modified - Cached version still valid
• 400 Bad Request - Malformed request
• 401 Unauthorized - Authentication required
• 403 Forbidden - Authenticated but not authorized
• 404 Not Found - Resource doesn't exist
• 429 Too Many Requests - Rate limited
• 500 Internal Server Error - Server code error
• 502 Bad Gateway - Upstream server error (proxy issue)
• 503 Service Unavailable - Server overloaded or maintenance
• 504 Gateway Timeout - Upstream timeout

• Host - REQUIRED in HTTP/1.1
• Authorization - Credentials
• Content-Type - Format of request body
• Accept - Preferred response formats
• If-None-Match - Conditional GET with ETag
• If-Modified-Since - Conditional GET with date
• User-Agent - Client identification
• Cookie - Session/state data

• Content-Type - Format of response body
• Content-Length - Body size in bytes
• Cache-Control - Caching directives
• ETag - Resource version identifier
• Last-Modified - Resource modification date
• Location - Redirect target or created resource URI
• Set-Cookie - Send cookie to client
• Access-Control-Allow-Origin - CORS permission

Need to read data? → GET
Need to check if exists without body? → HEAD
Need to see allowed methods? → OPTIONS

Need to create resource?
  ├─ Server assigns ID? → POST to collection (/users)
  └─ Client knows ID? → PUT to specific URI (/users/123)

Need to update resource?
  ├─ Full replacement? → PUT (send all fields)
  └─ Partial update? → PATCH (send changed fields only)

Need to delete resource? → DELETE

Key Takeaways

Insights & Reflection

The Philosophy of HTTP

HTTP in the Bigger Picture

Future Directions

Final Thought