Building a Simple HTTP Server in C for Learning Network Programming

Learning network programming is essential for understanding how the internet works. Building a simple HTTP server in C is a great way to grasp the basics of network communication, socket programming, and web protocols. This article guides you through creating a basic HTTP server to serve static pages, which is a foundational skill for more complex web server development. While modern web servers handle thousands of concurrent connections, the core principles of socket creation, binding, listening, and request handling remain unchanged. By writing a minimal server from scratch, you will gain a deep understanding of what happens behind the scenes when a browser fetches a page.

Prerequisites

  • Basic knowledge of C programming, including pointers, structures, and system calls
  • Understanding of network protocols, especially TCP/IP and the OSI model
  • A Unix-like environment (Linux, macOS, or WSL) with a C compiler (gcc or clang)
  • Familiarity with command-line tools and a text editor
  • Patience to debug low-level networking code

How a Web Server Works: The Big Picture

A web server listens on a TCP port, accepts incoming connections from clients (typically browsers), reads HTTP request messages, interprets them, and sends back HTTP response messages. The foundation of this communication is the Berkeley sockets API, which provides a standard interface for network I/O. The server must handle the following steps, often called the socket lifecycle:

  • Socket creation: Call socket() to create an endpoint for communication.
  • Binding: Associate the socket with a specific IP address and port using bind().
  • Listening: Mark the socket as passive using listen() to accept incoming connections.
  • Accepting: Accept a connection from the pending queue with accept().
  • Reading and writing: Use read() and write() (or send()/recv()) to exchange data with the client.
  • Closing: Terminate the connection with close().

This pattern is universal whether you are building a simple HTTP server or a production-grade service. Understanding each step thoroughly is critical. For a deeper dive into socket programming, refer to Beej's Guide to Network Programming.

Set Up the Development Environment

You need a Unix-like environment with a C compiler. On Linux, gcc is usually pre-installed. On macOS, you can install Xcode Command Line Tools. On Windows, use Windows Subsystem for Linux (WSL) or a MinGW environment. Compile and test simple C programs first to ensure your toolchain works. You will also need a web browser or a tool like curl to test your server.

Writing the Basic HTTP Server

We will create a single-threaded server that handles one client at a time. This is intentionally simplistic to focus on the core networking logic. The server will listen on port 8080 and return a fixed HTML page for every request.

Complete Example Code

Below is a well-commented implementation. Save it as server.c.

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <arpa/inet.h>
#include <sys/socket.h>

#define PORT 8080
#define BUFFER_SIZE 4096

int main() {
    int server_fd, new_socket;
    struct sockaddr_in address;
    socklen_t addr_len = sizeof(address);
    char buffer[BUFFER_SIZE] = {0};
    
    // HTTP/1.1 200 OK response with a small HTML body
    const char *http_response =
        "HTTP/1.1 200 OK\r\n"
        "Content-Type: text/html\r\n"
        "Content-Length: 46\r\n"
        "Connection: close\r\n"
        "\r\n"
        "<html><body><h1>Hello, World!</h1></body></html>";

    // 1. Create socket
    if ((server_fd = socket(AF_INET, SOCK_STREAM, 0)) == 0) {
        perror("socket failed");
        exit(EXIT_FAILURE);
    }

    // Optional: allow reuse of address and port after server restart
    int opt = 1;
    if (setsockopt(server_fd, SOL_SOCKET, SO_REUSEADDR, &opt, sizeof(opt))) {
        perror("setsockopt");
        close(server_fd);
        exit(EXIT_FAILURE);
    }

    // 2. Bind to port 8080 on any interface
    address.sin_family = AF_INET;
    address.sin_addr.s_addr = INADDR_ANY; // listen on all network interfaces
    address.sin_port = htons(PORT);        // convert to network byte order

    if (bind(server_fd, (struct sockaddr *)&address, sizeof(address)) < 0) {
        perror("bind failed");
        close(server_fd);
        exit(EXIT_FAILURE);
    }

    // 3. Listen for incoming connections (backlog = 3)
    if (listen(server_fd, 3) < 0) {
        perror("listen");
        close(server_fd);
        exit(EXIT_FAILURE);
    }

    printf("HTTP server listening on http://localhost:%d\n", PORT);

    // 4. Accept loop
    while (1) {
        printf("Waiting for a connection...\n");

        if ((new_socket = accept(server_fd, (struct sockaddr *)&address, &addr_len)) < 0) {
            perror("accept");
            continue;
        }

        // Print client IP address
        char client_ip[INET_ADDRSTRLEN];
        inet_ntop(AF_INET, &address.sin_addr, client_ip, INET_ADDRSTRLEN);
        printf("Connection from %s\n", client_ip);

        // 5. Read HTTP request
        ssize_t bytes_read = read(new_socket, buffer, BUFFER_SIZE - 1);
        if (bytes_read > 0) {
            buffer[bytes_read] = '\0';
            printf("Request:\n%s\n", buffer);
        }

        // 6. Send HTTP response
        write(new_socket, http_response, strlen(http_response));

        // 7. Close connection
        close(new_socket);
    }

    // (never reached in this example, but good practice)
    close(server_fd);
    return 0;
}

Step-by-Step Explanation

1. Socket Creation (socket())

socket(AF_INET, SOCK_STREAM, 0) creates an IPv4 TCP socket. AF_INET specifies the address family (IPv4), SOCK_STREAM indicates a reliable, connection-oriented byte stream (TCP). The third argument 0 lets the system choose the appropriate protocol (TCP for SOCK_STREAM). On error, socket() returns -1.

2. Binding (bind())

bind() attaches the socket to an IP address and port. INADDR_ANY binds the server to all available network interfaces, so clients can connect from any interface (including loopback). The port must be above 1024 unless running as root. htons() converts the port number from host byte order to network byte order (big-endian).

3. Listening (listen())

listen() marks the socket as a passive socket that can accept connections. The backlog parameter (here 3) specifies the maximum length of the pending connections queue. Once this queue is full, additional connection attempts will be refused.

4. Accepting (accept())

accept() blocks until a client connects. It returns a new socket file descriptor (new_socket) dedicated to communicating with that particular client. The original server_fd continues listening for other connections. The client_ip is extracted using inet_ntop() for logging.

5. Reading the Request

read() receives up to BUFFER_SIZE-1 bytes from the client. The HTTP request text is printed for debugging. In a real server, you would parse the request line and headers to determine which resource to serve.

6. Sending the Response

The HTTP response is constructed manually as a string. It includes the status line (HTTP/1.1 200 OK), required headers (Content-Type, Content-Length, Connection), a blank line (\r\n), and the body. Content-Length must match the exact byte count of the body. Connection: close tells the client that the server will close the connection after sending the response.

7. Closing the Connection

close(new_socket) frees the file descriptor. The server then loops back to accept() to wait for the next client.

Compiling and Testing

Compile the server code with:

gcc -Wall -Wextra -o simple_http_server server.c

Run the server (you may need sudo if you change the port to a privileged one):

./simple_http_server

Open a terminal and test with curl:

curl http://localhost:8080

You should see the HTTP response headers followed by the HTML body. Alternatively, open a web browser to http://localhost:8080; you should see "Hello, World!".

Going Further: Serving Static Files

The example above returns a hardcoded response. A more useful server would read a file from disk and serve it. Here's how to extend the code to serve HTML files from a www directory:

  1. Parse the request line to extract the file path (e.g., GET /index.html HTTP/1.1).
  2. Map the URI to a local file path, ensuring it stays within the document root (security: path traversal prevention).
  3. Open the file, determine its size, and read its contents.
  4. Construct a response with the appropriate Content-Type (e.g., text/html, text/css).
  5. Send the response using send() in a loop to handle partial writes.

For example, to detect .html files and set MIME types:

if (strstr(path, ".css")) {
    content_type = "text/css";
} else if (strstr(path, ".js")) {
    content_type = "application/javascript";
} else {
    content_type = "text/html";
}

This approach quickly evolves into a miniature file server. For a more comprehensive understanding of HTTP headers and status codes, consult RFC 7230 (HTTP/1.1 Message Syntax and Routing).

Handling Multiple Connections

The current server handles only one client at a time because accept() blocks until the next connection, and while processing one request, others queue up. To serve multiple clients concurrently, you have several options:

1. Fork for Each Connection

After accept(), call fork(). The child process handles the request and then exits, while the parent continues listening. This is simple but expensive for high-traffic servers.

2. Multithreading

Create a new thread per connection using pthreads. Be careful with thread safety and consider thread pooling.

3. Non-blocking I/O with select() or poll()

Use select() to monitor multiple file descriptors for readability. This allows a single thread to manage many connections efficiently. This is the foundation of event-driven servers like nginx. For a tutorial, see Handling Multiple Clients on Server without Multi-threading.

For production, modern servers often use epoll (Linux) or kqueue (BSD).

Error Handling and Robustness

Network programming is brittle. Always check return values of system calls. Common pitfalls include:

  • Broken sockets: The client may close the connection before or during the response. write() can return -1 with errno set to EPIPE. Handle gracefully.
  • Partial reads/writes: TCP streams do not guarantee that all bytes arrive in a single read(). Loop until all data is received or sent.
  • Buffer overflow: Never read() more bytes than the buffer can hold. Use bounded reads and null-terminate safely.
  • Timeout handling: Use setsockopt() with SO_RCVTIMEO and SO_SNDTIMEO to prevent hanging.
  • Signal handling: accept() may return EINTR if a signal is caught. Restart the system call or handle accordingly.

Always close file descriptors to avoid resource leaks. Use tools like valgrind to detect memory errors.

Security Considerations

Even a simple server has security implications. When you expand to serve arbitrary files, protect against:

  • Path traversal: A request like GET /../../../etc/passwd could expose sensitive files. Reject any URI containing .. or enforce a root directory using realpath checks.
  • Large payloads: A client could send a huge request to consume memory. Limit request sizes.
  • Denial of service: Accepting connections indefinitely without input validation can exhaust resources. Implement connection rate limiting.

For real-world use, consider using proven libraries like libevent or libmicrohttpd.

Conclusion

This simple HTTP server demonstrates the fundamental concepts of network programming in C: socket creation, binding, listening, accepting, and reading/writing. You have seen how to construct a valid HTTP response and how to handle one client at a time. Expanding it to serve files, support concurrency, and add robust error handling will deepen your understanding of how web servers operate under the hood. Building such projects enhances your ability to debug network issues and prepares you for more advanced system-level programming. For further study, explore the source code of lightweight HTTP server implementations or the definitive HTTP/1.1 specification.