404 Error not found
- Para usar el servidor usa make y ejecuta ./webserv. Por defecto usara el puerto 8080 y cualquier dirección IP.
- Para desplegar el cliente abre otro terminal y usa 'make client'. Se conectará al servidor.
- Para conectarte al servidor desde el navegador usa: http//localhost:8080
- La teoria del funcionamiento del server esta en src/Server.cpp
Temporary merge branch 2
Este proyecto consiste en implementar un servidor HTTP desde cero en C++, sin el uso de bibliotecas externas como Boost. El objetivo es comprender y construir la arquitectura fundamental de un servidor web como Nginx o Apache, respetando los estándares HTTP/1.1 y los requerimientos del subject.
- 🧾 Soporte para archivos de configuración tipo nginx (
.conf
) - 🌐 Servidor capaz de escuchar en múltiples puertos/IPs
- 👥 Manejo simultáneo de al menos 3 clientes
- 📩 Métodos HTTP soportados:
GET
,POST
yDELETE
- 🗂 Autoindex habilitado si no hay archivo index
- 🔁 Redirecciones 301 y 302
- 🧠 Manejo de códigos de estado HTTP correctos (200, 404, 500...)
- 🧨 Páginas de error personalizadas
- ⚙️ Soporte de CGI (por ejemplo: ejecutar scripts PHP o Python)
- 💾 Gestión de uploads via POST (por ejemplo:
multipart/form-data
) - 🧼 Liberación completa de recursos y sin memory leaks (
valgrind
)
- 🔁 Escalable (ideal para múltiples conexiones simultáneas)
- 🧱 Modular (fácil añadir PUT, HEAD, 301, cookies, etc.)
- 📦 Extensible (compatible con WebSocket y CGI)
- 🧵 Adaptable a multithread o single-thread eficiente
flowchart TD
A[Web Server (C++)]
A --> B[Parser]
B -->|Carga config| C[Server]
C --> D[Request Handler]
D --> E[Request Parsing]
D --> F[Action Execution]
D --> G[Response Builder]
F --> H[CGI Manager]
Nodo principal: es el servidor web escrito en C++, que contiene todos los componentes del sistema.
El servidor primero llama al Parser, que se encarga de leer y analizar el archivo de configuración .conf
, como en Nginx.
Una vez procesada la configuración, se pasa al módulo Server, que es el encargado de abrir sockets, escuchar en puertos/IPs definidos y aceptar conexiones.
Por cada conexión que llega, el servidor invoca el Request Handler, quien se encarga de procesar cada petición HTTP.
El handler primero interpreta la solicitud: método (GET
, POST
...), URI, headers, body, etc.
Luego ejecuta la acción correspondiente: buscar archivo, ejecutar CGI, borrar un recurso, etc.
Después, genera la respuesta HTTP adecuada con su código (200
, 404
...), headers y cuerpo.
Si la acción incluye ejecutar un script (por ejemplo PHP), se delega a CGI Manager, que se encarga de correr el script externo y devolver su salida como respuesta.
CONFIGURACIÓN → SERVIDOR → PETICIÓN → PARSEO → ACCIÓN (CGI o no) → RESPUESTA
[ epoll() ]
|
v
[ fd activo ] --> [ Connection Handler ]
|
v
[ Parser HTTP ]
|
v
[ Middleware Stack ]
| |
[Session] [Cookie]
|
v
[ Router ]
/ | \
CGI Static WebSocket
\ | /
[ Response ]
|
[ write() ]
webserv/
│
├── Makefile # Compilación principal
├── README.md # Documentación general del proyecto
├── LICENSE # (opcional) Licencia del proyecto
│
├── config/
│ └── server.conf # Configuración tipo NGINX
│
├── data/ # Recursos dinámicos
│ ├── uploads/ # Archivos subidos por usuarios
│ └── cgi-bin/ # Scripts CGI (PHP, Python, etc.)
│
├── www/ # Archivos estáticos del sitio web
│ └── index.html # Página por defecto
│
├── include/ # Headers del proyecto
│ ├── core/
│ │ ├── Server.hpp
│ │ ├── Poller.hpp
│ │ ├── Connection.hpp
│ │ └── EventLoop.hpp
│ ├── http/
│ │ ├── HttpRequest.hpp
│ │ ├── HttpResponse.hpp
│ │ └── HttpParser.hpp
│ ├── middleware/
│ │ ├── CookieMiddleware.hpp
│ │ ├── SessionMiddleware.hpp
│ │ └── LoggerMiddleware.hpp
│ ├── router/
│ │ ├── Route.hpp
│ │ └── Router.hpp
│ ├── handlers/
│ │ ├── StaticHandler.hpp
│ │ ├── CgiHandler.hpp
│ │ ├── WebSocketHandler.hpp
│ │ └── UploadHandler.hpp
│ ├── utils/
│ │ ├── Logger.hpp
│ │ ├── MimeTypes.hpp
│ │ └── StatusCodes.hpp
│ └── ConfigParser.hpp # Parser del archivo de configuración
│
├── src/
│ ├── main.cpp # Punto de entrada
│ ├── core/
│ │ ├── Server.cpp
│ │ ├── Poller.cpp
│ │ ├── Connection.cpp
│ │ └── EventLoop.cpp
│ ├── http/
│ │ ├── HttpRequest.cpp
│ │ ├── HttpResponse.cpp
│ │ └── HttpParser.cpp
│ ├── middleware/
│ │ ├── CookieMiddleware.cpp
│ │ ├── SessionMiddleware.cpp
│ │ └── LoggerMiddleware.cpp
│ ├── router/
│ │ ├── Route.cpp
│ │ └── Router.cpp
│ ├── handlers/
│ │ ├── StaticHandler.cpp
│ │ ├── CgiHandler.cpp
│ │ ├── WebSocketHandler.cpp
│ │ └── UploadHandler.cpp
│ ├── utils/
│ │ ├── Logger.cpp
│ │ ├── MimeTypes.cpp
│ │ └── StatusCodes.cpp
│ └── ConfigParser.cpp
│
├── tests/
│ ├── test_config/
│ ├── test_http/
│ ├── test_parser/
│ └── test_router/
│
└── docs/
├── architecture.md # Explicación de diseño
├── api.md # Especificaciones internas
├── bonus_checklist.md # Progreso de bonus
└── rfc/ # RFCs de referencia (copias locales opcionales)
-
HTTP/1.1 (RFC 2616 - Obsoleto)
https://www.w3.org/Protocols/rfc2616/rfc2616.html -
HTTP/1.1 actualizado (RFC 7230 a RFC 7235)
- Manual POSIX de
socket
,bind
,accept
,listen
,poll
, etc.
- ISO/IEC 14882:1998 — Lenguaje de programación C++
- [Consulta PDF proporcionado (tu archivo iso-cpp.pdf)]
- Alternativamente: https://cplusplus.com/doc/tutorial/
- Especificación CGI 1.1 (RFC 3875)
https://datatracker.ietf.org/doc/html/rfc3875 - Referencia de variables de entorno CGI
https://www.cgi101.com/book/ch3/text.html
- Documentación oficial:
- OpenSSL CLI (para generar certificados autofirmados)
- https://developer.mozilla.org/en-US/docs/Web/HTTP
Ideal para entender los códigos de estado, headers, y flujos de conexión HTTP.
Arquitectura | Descripción breve | Ventajas | Inconvenientes | ¿Viable para Webserv + bonus? |
---|---|---|---|---|
Monolítica | Toda la lógica en un solo binario o módulo | Fácil de desarrollar al principio | Difícil de mantener con múltiples funcionalidades | ❌ No recomendado |
Microservicios | Cada componente es un servicio independiente | Escalable, robusto, ideal para grandes sistemas | Muy complejo, necesitas red interna, contenedores, etc. | ❌ Excesivo para Webserv |
MVC (Model View Controller) | Separación entre lógica (Controlador), datos (Modelo) y presentación (Vista) | Facilita añadir rutas, lógica, vistas, respuestas estructuradas | No es nativa para servidores HTTP desde 0 | |
Reactor Pattern (💡) | Un loop de eventos que distribuye eventos I/O a manejadores (handlers) sin bloqueo | Ideal para poll()/select, escalable, usado en NGINX y Node.js | Requiere diseño claro de conexiones y estados | ✅ Sí. Ideal como núcleo de Webserv |
Multithread con Pool de Workers | Un hilo principal acepta conexiones y distribuye a un pool de threads | Muy eficiente para CPU-bound o CGI | Complejidad de sincronización | ✅ Sí, si quieres bonus multithread |
Pipeline/Middleware | Las solicitudes pasan por etapas (parser, router, lógica, respuesta) en cadena | Altamente extensible, ideal para agregar funcionalidades como sesiones | Necesita diseño modular, pero factible | ✅ Altamente recomendado |
Event-Driven + Middleware híbrido | Combinación del patrón Reactor + Pipeline interno | Máxima flexibilidad y escalabilidad | Requiere pensar en fases y estado por conexión | ✅ Arquitectura recomendada |