Building a Web Server

Your first task is to create the simplest possible program—one that immediately terminates when run. In this challenge, you will use the exit syscall, which is responsible for ending a process and returning an exit status to the operating system. This syscall takes a single argument: the exit status (with 0 typically indicating success). Understanding how to cleanly exit a program is crucial because it ensures your process communicates its completion state properly.

In this challenge, you’ll begin your journey into networking by creating a socket using the socket syscall. A socket is the basic building block for network communication; it serves as an endpoint for sending and receiving data. When you invoke socket, you provide three key arguments: the domain (for example, AF_INET for IPv4), the type (such as SOCK_STREAM for TCP), and the protocol (usually set to 0 to choose the default). Mastering this syscall is important because it lays the foundation for all subsequent network interactions.

NOTE: Looking through documentation, the arguments of the system calls are listed as names in all capitals. For instance, we may wish to call socket(AF_INET, SOCK_STREAM, 0) but we cannot simply perform mov rdi, AF_INET: AF_INET is simply not a concept at the assembly level. We need to find the integer which corresponds to AF_INET. These numbers are not even found in the man pages, but these numbers do exist on your machine. Check out the /usr/include directory. All the system's general-use include files for C programming are placed here. (For those who have written C, think of any header files you've included in your code "#include <stdio.h>". All those Functions and constants are defined somewhere here). Since C is compiled to assembly, these numbers are present somewhere in this directory. Rather than manually searching, you can grep for them.

After creating a socket, the next step is to assign it a network identity. In this challenge, you will use the bind syscall to connect your socket to a specific IP address and port number. The call requires the socket file descriptor, a pointer to a struct sockaddr, and the size of that structure. Back in Endian Escapades, you saw that x86 stores multi-byte values little-endian in memory, and that non-CPU contexts such as network protocols can use a different byte order. For IP socket structures, multi-byte numbers use big-endian order: the most-significant byte comes first. This convention is called network byte order. For a 16-bit port number, that means port 80 (0x0050) is represented as bytes 00 50. For IPv4, the structure is a struct sockaddr_in, and bind reads the 16 bytes at that pointer as fields:

bytes 0..1    address family, `AF_INET` (`2`)
bytes 2..3    port, in network byte order (`00 50` for port 80)
bytes 4..7    address (`0.0.0.0` is four zero bytes)
bytes 8..15   padding

Back in Opening the Flag, with RIP, you used stored bytes and passed their address to a syscall. Here, build the sockaddr_in bytes on the stack, pass the stack address as the pointer, and pass 16 as the size. On 64-bit x86, writing the word value 0x5000 stores the bytes 00 50, which is port 80 in network byte order. Binding is essential because it ensures your server listens on a known address, making it reachable by clients.

With your socket bound to an address, you now need to prepare it to accept incoming connections. The listen syscall transforms your socket into a passive one that awaits client connection requests. It requires the socket’s file descriptor and a backlog parameter, which sets the maximum number of queued connections. This step is vital because without marking the socket as listening, your server wouldn’t be able to receive any connection attempts.

Once your socket is listening, it’s time to actively accept incoming connections. In this challenge, you will use the accept syscall, which waits for a client to connect. When a connection is established, it returns a new socket file descriptor dedicated to communication with that client and fills in a provided address structure (such as a struct sockaddr_in) with the client’s details. This process is a critical step in transforming your server from a passive listener into an active communicator.

Now that your server can establish connections, it’s time to learn how to send data. In this challenge, your goal is to send a fixed HTTP response (HTTP/1.0 200 OK\r\n\r\n) to any client that connects. You will use the write syscall, which requires a file descriptor, a pointer to a data buffer, and the number of bytes to write. This exercise is important because it teaches you how to format and deliver data over the network.

In this challenge, your server evolves to handle dynamic content based on HTTP GET requests. You will first use the read syscall to receive the incoming HTTP request from the client socket. By examining the request line--particularly, in this case, the URL path--you can determine what the client is asking for. Next, use the open syscall to open the requested file and read to read its contents. Send the file contents back to the client using the write syscall. This marks a significant step toward interactivity, as your server begins tailoring its output rather than simply echoing a static message.

Previously, your server served just one GET request before terminating. Now, you will modify it so that it can handle multiple GET requests sequentially. This involves wrapping the accept-read-write-close sequence in a loop. Each time a client connects, your server will accept the connection, process the GET request, and then cleanly close the client session while remaining active for the next request. This iterative approach is essential for building a persistent server.

To enable your server to handle several clients at once, you will introduce concurrency using the fork syscall. When a client connects, fork creates a child process dedicated to handling that connection. Meanwhile, the parent process immediately returns to accept additional connections. With this design, the child uses read and write to interact with the client, while the parent continues to listen. This concurrent model is a key concept in building scalable, real-world servers.

Expanding your server’s capabilities further, this challenge focuses on handling HTTP POST requests concurrently. POST requests are more complex because they include both headers and a message body. You will once again use fork to manage multiple connections, while using read to capture the entire request. Again, you will parse the URL path to determine the specified file, but this time instead of reading from that file, you will instead write to it with the incoming POST data. In order to do so, you must determine the length of the incoming POST data. The obvious way to do this is to parse the Content-Length header, which specifies exactly that. Alternatively, consider using the return value of read to determine the total length of the request, parsing the request to find the total length of the headers (which end with \r\n\r\n), and using that difference to determine the length of the body--this seemingly more complicated algorithm may actually be easier to implement. Finally, return just a 200 OK response to the client to indicate that the POST request was successful.

In the final challenge, your server must seamlessly support both GET and POST requests within a single program. After reading the incoming request using read, your server will inspect the first few characters to determine whether it is dealing with a GET or a POST. Depending on the request type, it will process the data accordingly and then send back an appropriate response using write. Throughout this process, fork is employed to handle each connection concurrently, ensuring that your server can manage multiple requests at the same time. After completing this, you will have built a simple, but fully functional, web server capable of handling different types of HTTP requests.