Hasta ahora Escena Viva solo entrega: catálogo, sesiones, HTML, CSS. Todo son GET. Falta lo que convierte una web en una plataforma: recibir. Que alguien pueda comprar una entrada.

Y aquí aparece la asimetría del módulo. Leer req.method, req.url o req.headers es inmediato, porque Node te entrega esos datos ya analizados. El cuerpo, en cambio, no: cuando tu manejador empieza a ejecutarse, el cuerpo puede seguir viajando por la red. req es un stream de lectura, y leerlo es exactamente lo que aprendiste en el Módulo 3, con dos vueltas de tuerca nuevas: los trozos son Buffer y cortarlos mal rompe los caracteres, y quien los envía no está de tu lado, así que hay que ponerles un límite.

Al terminar tendrás src/servidor/cuerpo.js y el primer POST de Escena Viva: POST /pedidos, con validación, llamada al dominio y una respuesta 201 con su cabecera Location.

1. req es un stream: el cuerpo llega a trozos
2. Por qué concatenar en una cadena rompe los caracteres
3. La forma correcta: Buffer.concat y for await...of
4. El límite de tamaño y el 413
5. Tiempos límite y peticiones abortadas
6. Parsear según el Content-Type
7. POST /pedidos: validar y llamar al dominio
8. Responder 201 con Location, o el error que toque
9. Idempotencia: por qué un POST repetido duplica pedidos

Node invoca tu manejador en cuanto ha terminado de leer las cabeceras. El cuerpo llega después, en trozos, a través de los eventos del stream:

Tres cosas que hay que interiorizar:

• El tamaño de cada trozo no lo controlas. Depende del MTU de la red, del cliente y de los buffers del sistema. Un cuerpo pequeño puede llegar en un solo data; uno grande, en cientos. Nunca asumas que un trozo es una unidad con sentido.
• Si no lees el cuerpo, se queda ahí. Un manejador que responde sin consumir req deja datos sin leer en el socket, y con keep-alive eso puede desincronizar la siguiente petición de esa conexión. Si vas a ignorar el cuerpo, consúmelo (req.resume()) o destruye la petición.
• req emite error. Una conexión que se corta a media transmisión produce un error en el stream, y como todo EventEmitter, si no lo escuchas te tumba el proceso.

Este es el bug que más veces se ha escrito en la historia de Node:

El += convierte cada Buffer a cadena por separado, y ahí está la trampa que estudiamos en la lección 03-06: en UTF-8 un carácter puede ocupar varios bytes. ó son dos bytes (0xC3 0xB3); un emoji, cuatro. Si la frontera entre dos trozos cae en mitad de esa secuencia, cada mitad se decodifica por su cuenta y ninguna de las dos es un carácter válido: el resultado es � (U+FFFD), y esa sustitución es irreversible.

Lo perverso es cuándo falla: con cuerpos pequeños casi nunca hay más de un trozo, así que en desarrollo funciona siempre. En producción, con cuerpos mayores y una red real, falla de vez en cuando y solo con acentos, emojis o caracteres CJK. Un JSON.parse que revienta "aleatoriamente" y un usuario llamado "Bóveda" que a veces se guarda mal.

La regla es absoluta: acumula Buffer y decodifica una sola vez, al final. La alternativa, si necesitas ir procesando texto según llega, es el StringDecoder de la lección 03-06, que se guarda los bytes incompletos entre trozo y trozo.

Con async/await, req se recorre con for await...of, porque los streams de lectura son iterables asíncronos (lección 03-05). Queda mucho más legible que los eventos sueltos:

Ventajas sobre la versión con on('data'): los errores del stream se convierten en una excepción que captura tu try/catch, el end es simplemente el final del bucle, y el resultado encaja con el resto del código asíncrono. Es la forma que usaremos.

Pero tal cual, esa función es una invitación a que te tumben el servidor. Falta lo del apartado siguiente.

leerCuerpoCrudo acumula todo lo que llegue en memoria. Si un cliente envía un cuerpo de 5 GB, tu proceso intenta guardarlo en RAM y muere por falta de memoria. No hace falta mala fe: basta un bucle mal escrito en un cliente. Y con mala fe, es un ataque de denegación de servicio que cuesta una línea de curl.

Un servidor siempre limita el tamaño del cuerpo, y lo hace dos veces:

• Comprobando Content-Length antes de leer nada. Es barato y rechaza al instante lo obviamente enorme.
• Contando los bytes recibidos mientras llegan. Imprescindible, porque Content-Length lo escribe el cliente: puede mentir, o no venir en absoluto si la petición usa Transfer-Encoding: chunked.

El req.destroy() no es un detalle: sin él, el cliente sigue transmitiendo y tú sigues recibiendo bytes que descartas, gastando ancho de banda y CPU. Destruir la petición cierra el grifo.

CUERPO_DEMASIADO_GRANDE se añade a la tabla de errores-http.js con el estado 413 Payload Too Large:

Sobre el valor del límite: 64 KB es generoso para un pedido en JSON y ridículo para subir una imagen. La respuesta no es "un límite grande por si acaso", sino un límite distinto por ruta: 64 KB en la API, y varios megabytes solo donde de verdad se suben ficheros.

Hay un ataque más sutil que el cuerpo enorme: el cuerpo lentísimo. Un cliente anuncia 60 KB y los envía a razón de un byte por minuto. Nunca supera el límite de tamaño, pero mantiene una conexión y un manejador ocupados durante horas. Con unos cientos de conexiones así, agotas el servidor. Es el ataque conocido como slowloris.

La defensa es un tiempo límite:

El caso simétrico es la petición abortada: el usuario cierra la pestaña o pierde la cobertura a mitad de envío. Node lo señala en el stream, y conviene detectarlo para no hacer trabajo inútil:

La distinción clave es req.readableEnded: si es true, el cuerpo llegó completo y el close es el normal de después; si es false, la conexión se cortó antes. Cuando eso ocurre, no respondas: no hay nadie escuchando, y cualquier trabajo pesado que fueras a hacer (guardar en disco, llamar a otra API) es tiempo tirado.

Un cuerpo son bytes; qué significan lo dice la cabecera Content-Type. Estos son los tres formatos que verás:

Añadimos a src/servidor/cuerpo.js:

Detalles que importan. El Content-Type se corta por el ;, porque casi siempre viene con parámetros. El JSON.parse va en un try/catch y el mensaje se aprovecha: Unexpected token } in JSON at position 42 le dice al cliente exactamente dónde mirar, y eso vale mucho más que un "petición inválida". Y Object.fromEntries sobre URLSearchParams pierde las claves repetidas (se queda con la última): si tu formulario tiene casillas múltiples, usa getAll explícitamente.

Sobre multipart/form-data: es un formato con separadores generados al azar, partes con sus propias cabeceras, ficheros binarios que no deben pasar por memoria y codificaciones heredadas. Parsearlo a mano es un error de juicio: se resuelve con busboy o multer, que veremos en el Módulo 6. Saber que no hay que hacerlo a mano es parte del oficio.

Con las piezas listas, el primer POST de Escena Viva. El cuerpo esperado es mínimo: {"sesionId": "ses-001-1", "cantidad": 2, "correo": "[email protected]"}.

La validación se hace a mano y antes de tocar el dominio. Cada comprobación lanza con su error.codigo, y el manejador central de 04-03 los convierte en el estado que toca:

Cuatro criterios detrás de estas comprobaciones:

• Number.isInteger, no parseInt. Con parseInt('2 entradas') obtendrías 2 y darías por buena una barbaridad. Si el cuerpo es JSON, cantidad debe llegar como número; una cadena "2" es un cliente mal escrito y merece un 400.
• Se distingue 400 de 422. cantidad: 0 es un 400 (el valor no tiene sentido); cantidad: 8 es un 422 (el valor es válido y la regla de negocio lo prohíbe).
• Se valida antes de llamar al dominio. Cuanto antes se rechaza lo inválido, menos estado a medias hay que deshacer.
• Se normaliza al final. Recortar espacios y bajar el correo a minúsculas evita que "[email protected]" y "[email protected]" sean dos clientes distintos.

Con los datos ya limpios, el manejador solo orquesta:

Fíjate en lo que no hay: ni un solo try/catch, ni una sola mención a un número de estado HTTP. El manejador lanza en el vocabulario del dominio y el despachador traduce. Esa es la recompensa de las dos lecciones anteriores.

Un POST que crea un recurso responde 201 Created con la cabecera Location apuntando a dónde ha quedado:

El Location no es decorativo: es lo que permite a un cliente guardar la URL del pedido sin construirla él a base de suposiciones. Y el importe va en céntimos enteros, la convención del proyecto desde el Módulo 1: 2 × 2500 = 5000, nunca 50.00 en coma flotante.

Todos los caminos de error, en una tabla:

Y la comprobación completa desde la terminal:

La sesión ses-002-1 tiene aforo 120 y 118 vendidas: pedir 5 devuelve 409 con el mensaje del dominio, que dice cuántas quedan. Ese detalle —un error que explica el estado real— es lo que convierte una API en algo usable.

Ejecuta dos veces el curl que crea el pedido de 2 entradas. Obtendrás dos pedidos distintos y cuatro entradas vendidas. Es correcto según la norma: POST no es idempotente por definición, y repetirlo significa crear otro recurso.

El problema es que en la vida real las peticiones se repiten sin querer: el usuario pulsa dos veces "Comprar", la red se corta después de que el servidor procesara el pedido pero antes de que llegara la respuesta, o un cliente móvil reintenta automáticamente. En una plataforma de entradas eso significa cobrar dos veces.

Las tres defensas, en orden de solidez:

1. En el cliente: deshabilitar el botón tras el primer clic. Necesario, insuficiente: no protege de un reintento de red.
2. Clave de idempotencia: el cliente genera un identificador único por intento y lo envía en una cabecera Idempotency-Key. El servidor la guarda con la respuesta; si llega otra vez la misma clave, devuelve la respuesta guardada sin volver a ejecutar nada. Es lo que hacen las pasarelas de pago.
3. Transacciones en la base de datos: reservar aforo y crear el pedido en una operación atómica, con una restricción de unicidad que impida el duplicado.

Nuestro servidor hoy no puede hacer bien ni la 2 ni la 3, y conviene ser honestos sobre por qué: el estado vive en memoria y en un JSON de disco, sin transacciones ni bloqueos. Es más: dos peticiones simultáneas pueden leer el mismo aforo libre y vender las mismas dos butacas, una condición de carrera clásica. Lo resolveremos de verdad en la lección 07-06, con transacciones. Hasta entonces, tenlo presente como lo que es: una limitación conocida, no un descuido.

• Acumular el cuerpo en una cadena con +=. Rompe los caracteres multibyte de forma intermitente. Buffer.concat y decodificar al final.
• Leer el cuerpo sin límite de tamaño. Un cliente te agota la memoria con una línea de curl. Comprueba Content-Length y cuenta los bytes.
• Fiarse solo de Content-Length. Lo escribe el cliente y con chunked ni siquiera existe.
• No destruir la petición al superar el límite. Sigues recibiendo lo que ya has decidido descartar.
• JSON.parse sin try/catch. Un cuerpo malformado te da un 500 en lugar de un 400, y una traza en el registro por cada cliente torpe.
• Comparar el Content-Type con ===. Casi siempre trae ; charset=utf-8. Córtalo por el ;.
• Responder 200 a una creación, o parsear multipart/form-data a mano. Un POST que crea devuelve 201 con Location; para multipart, busboy o multer.
• Consejo: valida antes de tocar el dominio y normaliza al final (recortar, minúsculas). Es más barato rechazar que deshacer.
• Consejo: en los mensajes de error, incluye el dato que falla y el valor esperado. "Maximo 6 entradas por pedido, se han pedido 8" vale infinitamente más que "Peticion invalida".

Escribe src/laboratorio/romper-utf8.js que construya el Buffer de '{"sala":"Sala Bóveda","evento":"Concierto de Otoño"}', lo parta en trozos de 7 bytes, y compare dos reconstrucciones: la de concatenar cadenas y la de Buffer.concat. Muestra ambas, cuenta los caracteres � de cada una e intenta JSON.parse en las dos. Repite con trozos de 5 y de 13 bytes.

Genera un fichero de 100 KB (node -e "process.stdout.write('x'.repeat(102400))" > /tmp/grande.txt) y envíalo con curl -X POST --data-binary @/tmp/grande.txt. Comprueba que la respuesta es 413. Después modifica leerCuerpo para que registre en stderr cuántos bytes se llegaron a recibir antes de cortar, y explica por qué ese número casi nunca coincide exactamente con el límite.

Haz que POST /pedidos acepte también application/x-www-form-urlencoded, teniendo en cuenta que en un formulario todos los valores llegan como cadena y cantidad debe convertirse a número antes de validarla. Comprueba con curl -d 'sesionId=ses-003-1&cantidad=3&[email protected]' (sin -H, porque curl ya pone ese Content-Type) y asegúrate de que cantidad=tres sigue devolviendo 400.

Solución 1. Con trozos de 7 bytes el corte cae dentro de la ó de "Bóveda" y de la ñ de "Otoño":

Buffer.concat devuelve el original en los tres casos; la concatenación de cadenas rompe caracteres siempre que un corte caiga dentro de una secuencia multibyte, y su JSON.parse falla porque � no es un carácter válido dentro de una cadena JSON... salvo que caiga dentro de un valor, en cuyo caso parsea sin error y guarda datos corruptos, que es el escenario peor de todos.

Solución 2. El número casi nunca coincide con el límite porque la comprobación se hace después de recibir un trozo entero: si el límite son 65.536 bytes y el trozo que lo cruza trae 16 KB, te habrás pasado en varios miles. Es el comportamiento correcto —no puedes rechazar medio trozo—, y por eso el límite se elige con margen y no al milímetro.

Solución 3. La conversión debe ser estricta: Number('tres') es NaN, y Number.isInteger(NaN) es false, así que la validación existente ya lo rechaza sin tocarla.

Usar Number y no parseInt es deliberado: parseInt('3 entradas') devuelve 3 y aceptaría basura, mientras que Number('3 entradas') devuelve NaN y la rechaza. La sesión ses-003-1 tiene aforo suficiente, así que el pedido de 3 entradas devuelve 201.

Escena Viva ya vende entradas. Y el camino ha dejado claro que recibir es bastante más delicado que entregar. req es un stream de lectura cuyos trozos son Buffer de tamaño impredecible, así que la primera regla es acumular Buffer y decodificar una sola vez con Buffer.concat: concatenar en una cadena parte los caracteres multibyte y produce � irrecuperables de forma intermitente, justo el tipo de fallo que no aparece en desarrollo. Con for await...of el código queda además legible y con los errores integrados en try/catch.

La segunda regla es que quien envía el cuerpo no está de tu lado: src/servidor/cuerpo.js comprueba Content-Length como filtro barato y cuenta los bytes recibidos como filtro real, destruye la petición al pasarse y lanza CUERPO_DEMASIADO_GRANDE → 413. A eso se suman req.setTimeout contra el cuerpo lentísimo y la detección de abortos con close más readableEnded, para no trabajar por nadie. El parseo se decide por el Content-Type cortado por el ;: JSON.parse en try/catch con su mensaje aprovechado, URLSearchParams para los formularios, y multipart/form-data delegado a una librería porque hacerlo a mano es un error de juicio.

Y tienes el primer POST real: validación a mano antes de tocar el dominio —Number.isInteger en vez de parseInt, 400 para lo que no tiene sentido y 422 para lo que la regla de negocio prohíbe, con el límite de 6 entradas—, llamada a reservar y a GestorDeVentas, y respuesta 201 con Location e importe en céntimos. Todo sin un solo try/catch en el manejador: lanza en el vocabulario del dominio y el despachador de 04-03 traduce. Sabes también lo que aún no está resuelto: un POST repetido duplica el pedido, y dos simultáneos pueden vender la misma butaca. La solución tiene nombre —claves de idempotencia y transacciones— y fecha: la lección 07-06.

Nos queda darle la vuelta al papel. Hasta ahora Node ha sido siempre el servidor; en la próxima lección, Consumiendo APIs Externas desde Node.js, será el cliente: fetch global y http.request por debajo, el error clásico de que fetch no rechaza ante un 404 ni un 500, tiempos límite con AbortController, reintentos con espera exponencial reutilizando reintentar del Módulo 2, y un servicio real de Escena Viva —src/servicios/cambio-divisas.js— con caché en memoria y degradación elegante cuando el proveedor externo falla.