<<<<<<<<< Temporary merge branch 1

WEBSERV

SERVER

• 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.

NAVEGADOR

• Para conectarte al servidor desde el navegador usa: http//localhost:8080

TEORIA

• La teoria del funcionamiento del server esta en src/Server.cpp

Temporary merge branch 2

Webserv - Proyecto 42

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.

---

✅ Requisitos obligatorios

• 🧾 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 y DELETE
• 🗂 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)

---

🧱 Arquitectura general

📐 Arquitectura Elegida: Event-Driven + Middleware + Router Modular

📊 Ventajas:

• 🔁 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]

Loading

🧠 Explicación paso a paso

A[Web Server (C++)]

Nodo principal: es el servidor web escrito en C++, que contiene todos los componentes del sistema.

A --> B[Parser]

El servidor primero llama al Parser, que se encarga de leer y analizar el archivo de configuración .conf, como en Nginx.

B -->|Carga config| C[Server]

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.

C --> D[Request Handler]

Por cada conexión que llega, el servidor invoca el Request Handler, quien se encarga de procesar cada petición HTTP.

D --> E[Request Parsing]

El handler primero interpreta la solicitud: método (GET, POST...), URI, headers, body, etc.

D --> F[Action Execution]

Luego ejecuta la acción correspondiente: buscar archivo, ejecutar CGI, borrar un recurso, etc.

D --> G[Response Builder]

Después, genera la respuesta HTTP adecuada con su código (200, 404...), headers y cuerpo.

F --> H[CGI Manager]

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.

---

🔄 Flujo resumido

CONFIGURACIÓN → SERVIDOR → PETICIÓN → PARSEO → ACCIÓN (CGI o no) → RESPUESTA

---

🗂 Componentes Principales:

epoll()

[ epoll() ]
    |
    v
[ fd activo ] --> [ Connection Handler ]
                      |
                      v
              [ Parser HTTP ]
                      |
                      v
              [ Middleware Stack ]
                  |       |
          [Session]   [Cookie]
                  |
                  v
               [ Router ]
             /     |     \
         CGI   Static   WebSocket
             \     |     /
              [ Response ]
                  |
               [ write() ]

---

🌲 Árbol del Proyecto

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)

🌐 Documentación Oficial Relevante para el Proyecto Webserv 📘

1. Protocolo HTTP

• HTTP/1.1 (RFC 2616 - Obsoleto)
  https://www.w3.org/Protocols/rfc2616/rfc2616.html

• HTTP/1.1 actualizado (RFC 7230 a RFC 7235)

  • RFC 7230 - Message Syntax and Routing
  • RFC 7231 - Semantics and Content
  • RFC 7235 - Authentication

2. Sockets y Redes en UNIX (POSIX)

• Manual POSIX de socket, bind, accept, listen, poll, etc.
  • https://man7.org/linux/man-pages/dir_section_2.html
  • https://man7.org/linux/man-pages/man2/socket.2.html
  • https://man7.org/linux/man-pages/man2/poll.2.html

3. Estándar C++98

• ISO/IEC 14882:1998 — Lenguaje de programación C++
  • [Consulta PDF proporcionado (tu archivo iso-cpp.pdf)]
  • Alternativamente: https://cplusplus.com/doc/tutorial/

4. Documentación CGI

• 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

5. NGINX

• Documentación oficial:
  • https://nginx.org/en/docs/
  • https://nginx.org/en/docs/http/configuring_https_servers.html
  • https://nginx.org/en/docs/http/ngx_http_proxy_module.html

6. Certificados SSL para desarrollo

• OpenSSL CLI (para generar certificados autofirmados)
  • https://www.openssl.org/docs/man1.1.1/man1/openssl.html
  • https://wiki.openssl.org/index.php/Command_Line_Utilities

7. Referencia HTTP de Mozilla Developer Network (MDN)

• https://developer.mozilla.org/en-US/docs/Web/HTTP
  Ideal para entender los códigos de estado, headers, y flujos de conexión HTTP.

---

🧠 Análisis de Arquitecturas Posibles para Webserv

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	⚠️ Interesante para capas internas
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