ymawky: el servidor web escrito completamente en ensamblador ARM64 que desafía las convenciones del desarrollo
En un panorama dominado por servidores web escritos en lenguajes de alto nivel como C, Go o Rust, un proyecto experimental está dando que hablar en la comunidad de desarrollo: ymawky, un servidor web implementado íntegramente en ensamblador ARM64. La iniciativa, publicada en GitHub, se presenta como un proyecto de programación a mano que prescinde de bibliotecas estándar y depende únicamente de llamadas al sistema (syscalls), con un modelo fork-per-connection para manejar cada petición.
Según la documentación oficial del repositorio, ymawky fue desarrollado originalmente para macOS, aunque la rama actual constituye un porte completo para Linux. Para su compilación se requieren las herramientas gcc y binutils, y puede obtenerse un binario optimizado mediante "make" o una versión con símbolos de depuración usando "make debug". Por defecto, el servidor escucha en 127.0.0.1:8080, aunque acepta un puerto personalizado como argumento. El proyecto solo opera en la dirección loopback, limitación que su autor admite como pendiente y que, en tono irónico, califica como "una característica de seguridad" involuntaria.
En cuanto a capacidades, ymawky ofrece un abanico de funciones sorprendentemente amplio para un servidor escrito a bajo nivel. Soporta los métodos HTTP GET, PUT, DELETE, OPTIONS, HEAD y POST (este último únicamente a través de scripts CGI). Implementa decodificación de porcentajes en URLs, detección de tipos MIME, parseo del encabezado Content-Length y una protección básica contra ataques de denegación de servicio tipo slowloris, con un tiempo máximo de diez segundos para recibir los datos de la petición. Además, gestiona rangos de bytes en solicitudes GET —incluidos rangos completos, sufijos y rangos abiertos— lo que permite funcionalidades como la búsqueda en vídeos.
La seguridad ha sido una preocupación central para el desarrollador. El servidor rechaza rutas que excedan PATH_MAX (4096 bytes), bloquea intentos de path traversal como "../", confina todas las peticiones al directorio www/ y rechaza cualquier enlace simbólico gracias al flag O_NOFOLLOW_ANY. Las operaciones PUT se realizan de forma atómica: los datos se escriben primero en un archivo temporal y, tras completarse la transferencia, se renombran al destino final, lo que evita archivos corruptos en caso de interrupciones. Esta operación admite subidas de hasta 1 GiB, configurables a tamaños mayores.
El soporte para CGI (Common Gateway Interface) es uno de los aspectos más llamativos del proyecto. Los scripts deben ubicarse en un directorio cgi-bin/ configurable, y el servidor procesa cadenas de consulta, reenvía variables de entorno estándar y respeta el encabezado Status: para determinar el código HTTP de respuesta. Sin embargo, el propio autor advierte que esta funcionalidad es experimental y carece de los estrictos mecanismos de timeout aplicados a PUT: un script CGI podría, teóricamente, ejecutar un bucle infinito sin que ymawky lo interrumpa. La recomendación explícita del desarrollador es contundente: "no debería ejecutar ymawky en un servidor real (lol)".
En el plano protocolar, ymawky implementa un número considerable de códigos de estado HTTP, desde los habituales 200, 404 y 500 hasta opciones más singulares como 418 "I'm a teapot", 416 "Range Not Satisfiable" o 503 "Service Unavailable". También interpreta la versión HTTP del cliente y exige el encabezado Host: en las peticiones HTTP/1.1, en cumplimiento con la RFC 9112, sección 3.2, aunque actualmente no procesa su contenido. Cuando una petición resulta en error, el servidor busca páginas estáticas personalizadas en un directorio err/ (por ejemplo, err/404.html).
El proyecto se enmarca claramente en la categoría de экспериментального desarrollo más que de herramienta productiva. Su autor es transparente sobre las limitaciones y posibles vulnerabilidades, pero subraya los esfuerzos por implementar medidas defensivas razonables. La existencia de ymawky ilustra hasta qué punto es posible construir software funcional de red partiendo únicamente de las primitivas más básicas del sistema operativo, y supone un ejercicio de ingeniería poco común que combina nostalgia por la programación de bajo nivel con un conocimiento detallado de las especificaciones HTTP contemporáneas. Para la comunidad técnica, se trata ante todo de una demostración de habilidad y un recurso educativo sobre el funcionamiento interno de los servidores web, más que de una alternativa lista para producción.