2025
Webserv
An HTTP/1.1 web server in C++ built by a team of three. It serves many clients with non-blocking I/O and poll, reads its settings from a configuration file, and handles GET, POST and DELETE, static files, directory listing, redirections, CGI, file uploads and chunked transfer encoding.
My role
Three-person team. I owned request handling and routing: parsing HTTP requests (GET, POST and DELETE, with headers, bodies and chunked bodies), mapping URLs to files and directories, directory listing, default files and redirections.
Context
Webserv is a team project from the 42 curriculum: write an HTTP server from scratch in C++. The work was split into three layers. My teammates built the core server (sockets, the poll loop, configuration parsing and error pages) and the advanced features (CGI, file uploads, and bonus cookies, sessions and multiple CGI handlers). I built the layer in between.
Problem
A web server has to serve many clients at once without blocking on any of them, read HTTP requests correctly (headers, bodies and chunked bodies), and send each URL to the right place: a file, a directory listing, a redirect or a CGI script.
What I built
Request parsing
I wrote the parser for HTTP requests. It handles GET, POST and DELETE, the headers, the body, and chunked request bodies.
Routing
I mapped each URL to a file or a directory. The router serves default files, produces a directory listing (autoindex) when there is no default, and supports HTTP redirections.
Architecture
A server that uses non-blocking I/O with poll to handle many clients without blocking. A configuration file defines how it runs. Each request is parsed, routed to a file, a directory listing, a redirect or a CGI script, and answered with a default or custom error page when something fails, with limits on the client body size. The repository holds config/, includes/, srcs/, www/, a Makefile and test scripts for the server, CGI and chunked POST.
Key decisions and trade-offs
Handle many clients with non-blocking I/O and poll, not a thread per connection.
Trade-off: One loop serves every client without blocking on any of them. The cost is that everything, including request parsing, has to cope with data arriving in pieces.
Split the server into three layers: core and configuration, request handling and routing, and advanced features.
Trade-off: Each of us could work on a layer in parallel. The cost is that the interfaces between the layers have to be agreed early.
Outcome
A working server with GET, POST and DELETE, CGI, file uploads, directory listing, redirections, chunked transfer encoding, custom error pages and client body size limits, plus bonus cookies and sessions. The repository includes test scripts for the server, CGI and chunked POST.
Stack
- C++
- HTTP/1.1
- Sockets
- CGI
- Networking