>_
GolangStepByStep
Software Engineer

HTTP Servers

Middleware, request lifecycle, graceful shutdown

# What is an HTTP Server? (The Mega Store Analogy)

Imagine you own a massive Mega Store.

The building itself, with its walls, doors, and foundation, is the http.Server. The signs hanging from the ceiling pointing people to "Electronics" or "Groceries" are the Router (http.ServeMux). The employees standing in those aisles helping customers are your Handlers.

When working with Go's web features, many developers focus entirely on the Handlers (the employees). But if the building's doors (the Server) don't have strict security guards (Timeouts and Middleware), a mob of slow, confusing customers can enter the store, stand still in the aisles, and cause your entire business to physically collapse.

# Level 1: The Basic "Building" (Beginner)

The fastest way to open your store is using Go's built-in convenience function. It takes two arguments: an address (like a street address), and a router (the signposts).

package main

import (
    "fmt"
    "net/http"
)

func main() {
    // 1. Create a Router (The Store Directory)
    mux := http.NewServeMux()
    
    // 2. Add an Employee (Handler) to the /hello aisle
    mux.HandleFunc("/hello", func(w http.ResponseWriter, r *http.Request) {
        fmt.Fprint(w, "Welcome to the store!")
    })

    // 3. Open the doors! (Binding to port 8080)
    // NOTE: This is EASY, but dangerously insecure for production.
    fmt.Println("Store is open on port 8080...")
    http.ListenAndServe(":8080", mux)
}

This works beautifully for local development. But if you deploy this to the open internet, you will eventually face a crisis. Why? Because ListenAndServe has No Rules.

# Level 2: Setting Store Rules with Timeouts (Intermediate)

Imagine a malicious customer walks into your store, walks up to the cashier, and says: "I would like to order a..." and then pauses for 3 hours.

Without rules, your employee will stand there forever waiting. If 1,000 customers do this, all your employees are paralyzed. This is called a Slowloris Attack. To fix it, you cannot use the simple http.ListenAndServe. You must build your own http.Server struct and give it Timeouts.

package main

import (
    "net/http"
    "time"
    "log"
)

func main() {
    mux := http.NewServeMux()
    mux.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
        w.Write([]byte("Safe and sound!"))
    })

    // Construct a custom Server explicitly
    server := &http.Server{
        Addr:         ":8080",
        Handler:      mux,
        
        // RULES:
        // You have 3 seconds to tell me your HTTP Headers.
        ReadHeaderTimeout: 3 * time.Second,
        
        // You have 5 seconds total to send your whole request.
        ReadTimeout:       5 * time.Second,
        
        // I have 10 seconds to write back to you before I abort.
        WriteTimeout:     10 * time.Second,
        
        // Don't hang around longer than 15s between requests.
        IdleTimeout:      15 * time.Second,
    }

    log.Println("Secure Server starting...")
    // Now we use the server struct's method directly
    log.Fatal(server.ListenAndServe())
}

Golden Rule: Every production Go application that faces the internet MUST use explicit http.Server timeouts.

# Level 3: Middleware and ServeMux (Advanced)

Now that the building is secure, we need Store Security Cameras. We want to log every single person who walks through the front door, regardless of which aisle they go to.

We do this by wrapping our Router (the Mux) inside a Middleware function.

// A Middleware is a function that takes a Handler, and returns a Handler
func LoggerMiddleware(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        
        // 1. DO BEFORE:
        log.Printf("Incoming: %s %s", r.Method, r.URL.Path)
        
        // 2. PASS TO THE REAL DESTINATION:
        next.ServeHTTP(w, r)
        
        // 3. DO AFTER:
        log.Printf("Done with: %s", r.URL.Path)
    })
}

func main() {
    mux := http.NewServeMux()
    mux.HandleFunc("/buy", purchaseHandler)
    mux.HandleFunc("/refund", refundHandler)

    srv := &http.Server{
        Addr: ":8080",
        // Notice we WARP the mux in our Logger!
        // Now EVERY request gets logged before hitting the Mux.
        Handler: LoggerMiddleware(mux), 
    }
    
    srv.ListenAndServe()
}

# Level 4: The Request Context Lifecycle (Expert)

What happens if a customer orders a highly complex, custom cake that takes 10 minutes to bake... but then they silently leave the store 1 minute in?

Your server will foolishly waste 9 minutes baking a cake for a ghost. To fix this, Go HTTP servers deeply integrate with context.Context.

Every incoming http.Request has a built-in context attached to it: r.Context(). If the client disconnects, closes their browser, or hits a server timeout, the Server instantly cancels that Context. You can listen for this cancellation in your handlers!

func HeavyTaskHandler(w http.ResponseWriter, r *http.Request) {
    ctx := r.Context()
    
    // Simulate a database query that takes 5 seconds
    queryChan := make(chan string)
    go func() {
        time.Sleep(5 * time.Second)
        queryChan <- "Data from DB!"
    }()

    select {
    // SCENARIO 1: The database finishes first. Success!
    case result := <-queryChan:
        fmt.Fprint(w, result)

    // SCENARIO 2: The client closed their browser! The context cancels.
    case <-ctx.Done():
        // We halt instantly! Saving massive CPU/DB resources.
        log.Println("Client gave up. Halting operation.")
        return 
    }
}

Combining explicit server timeouts with strict Context propagation down to your database queries makes Go servers practically indestructible under heavy load.

practice & review