Webserv Refactor

A lightweight, fully custom HTTP/1.1 server originally developed as a team project for the 42 cursus, built and tested on Linux systems. This repository is my personal continuation of the project, focusing on incremental refactoring, modularization, and performance exploration.

---

Origin

The original project was implemented collaboratively during the 42 curriculum. This repository preserves the core functionality while progressively improving:

• architecture clarity
• configuration flexibility
• execution workflow

---

Features (original project)

• HTTP/1.1 compliant: GET, POST, HEAD, DELETE; persistent connections; chunked transfer encoding
• IO multiplexing via epoll
• CGI support: Python and PHP scripts, configurable interpreters, proper handling of timeouts and errors
• Nginx-like configuration: multiple server blocks, location-based routing
• Static file serving, autoindex, aliases, custom error pages, file uploads
• Multiple virtual hosts on shared sockets
• Minimal process model: single main process for connections, forked children only for CGI

---

My Contributions (original project)

• Implemented and maintained configuration system (ConfigManager, ServerInfo, Location)
• Contributed to HTTP request parsing and chunked file upload handling
• Fixed bugs and completed tasks in collaboration with team code
• Developed scripts to test HTTP requests, responses, and status codes

---

Refactored Contributions

Change 1: Environment-based root configuration

• What: Introduced $WEBSERV_ROOT to decouple project root paths from hard-coded values, implemented via expandEnvVars().
• Why: Allows flexible deployment and testing across different environments without modifying configuration files.

Change 2: Unified build and execution workflow

• What: Added start.sh script to build and start Webserv in a single command.
• Why: Simplifies development workflow, automatically handles header changes, and sets required environment variables.

Change 3: Response handling refactor

• What: Extracted HTTP response generation logic into a dedicated module, separating response construction from request parsing and routing.
• Why: Improves code modularity and clarity by enforcing a cleaner separation of concerns, making the request lifecycle easier to maintain, extend, and debug.

---

Thread Pool (prototype)

A basic thread pool has been implemented as a standalone module.

• Includes:
  • task queue
  • worker threads
  • condition variable synchronization
• Current status:
  • Not yet integrated into the main request pipeline
  • Under evaluation for CPU-bound task delegation (e.g. CGI execution)

This is part of ongoing experimentation with concurrency strategies in an event-driven server architecture.

---

Current Focus

• Clarifying the full HTTP request lifecycle: epoll → connection → parsing → response

• Evaluating concurrency strategies for CPU-bound workloads (thread pool design consideration, not yet integrated)

• Studying request/connection state modeling to better structure event-driven flow

• Investigating robustness issues in CGI handling and edge cases

---

Usage (one-command startup)

# Build and start Webserv
./start.sh ["path of config file"]