Lo que el servidor web tiene que dejar de decidir

Si tu sitio va detrás de un servidor web que decide qué rutas existen, esta nota describe un fallo que aparece solo en producción, solo en las páginas nuevas, y que nadie relaciona con el servidor.

La escena se repetía cada vez que añadíamos una página. Compilaba bien. Respondía perfectamente en el servidor de desarrollo. Se desplegaba. Y en producción daba 404.

La causa estaba en la configuración del servidor web. Tenía una lista blanca de prefijos —estas rutas van a la aplicación— y todo lo que no estuviera en ella caía en el manejo de archivos estáticos, o sea, en un 404.

Una ruta nueva no existía hasta que alguien se acordaba de añadirla a mano, en otro archivo, en otra máquina.

Y el error no ayudaba nada: un 404 limpio. No decía «esta ruta no está en la lista», decía «esto no existe», que es lo mismo que diría una página que de verdad no existe.

La pregunta que arregla esto no es «cómo mantengo la lista sincronizada». Es: ¿quién sabe qué rutas existen?

Y la respuesta es una sola: el enrutador de la aplicación. Es el único que lo sabe, porque es el único que ve el código. Cualquier otro sitio donde se escriba esa lista es una copia, y una copia que vive en otra máquina y que solo se toca al desplegar es la peor clase de copia.

Así que el servidor web dejó de decidirlo. Ahora manda todo lo que no sea un archivo estático a la aplicación, y que ella conteste lo que tenga que contestar — incluido el 404, que al menos será el 404 de quien sabe.

Ese fallo ya no puede ocurrir. No está mitigado: es imposible.

Delegar no es quitarle el trabajo a nadie. Hay cosas que el servidor web hace mejor, y se quedan.

El criterio para repartir: lo que cambia con el código, va en el código. Lo que es propiedad del despliegue —certificados, puertos, archivos en disco— se queda fuera.

Los archivos con nombre de huella son un buen ejemplo de la segunda columna: servidos desde disco sobreviven al despliegue, así que quien tenía la página abierta no se queda sin ellos a media navegación.

Un apunte sobre algo que casi nadie hace y que es barato.

Tuvimos unas rutas en castellano que vivieron poco: se publicaron, se renombraron a inglés al reorganizar el sitio. Podrían haberse borrado sin más.

En su lugar hay una redirección permanente. Cuesta una línea y evita romper cualquier enlace ya compartido — un mensaje de WhatsApp de hace tres meses, un correo, un enlace que alguien guardó.

Y hay un detalle que se suele olvidar: apuntar a la forma exacta, sin barra al final si el sitio no la usa. Si no, se encadena una segunda redirección de propina, y cada salto es tiempo que paga quien hizo clic.

Esta historia es un caso particular de algo que aparece en todas partes: una lista que hay que mantener sincronizada con un hecho.

La configuración del servidor con las rutas. El trabajador de servicio con la lista de lo que no debe guardar en caché. Un archivo de despliegue con la lista de páginas. Cada uno es una copia de algo que ya sabe otro.

Hay tres salidas, y conviene buscarlas en este orden:

• Delegar. Que decida quien sabe. Es lo que se hizo aquí.
• Derivar. Generar la lista de la fuente real, como hace nuestro mapa del sitio.
• Invertir. Si no queda otra que una lista, que el olvido falle del lado seguro: que lo no listado sea lo restrictivo, no lo permisivo.

Lo que no es una salida es un comentario pidiendo que alguien se acuerde.

• Si una página nueva te da 404 solo en producción, mira el servidor web. No la aplicación. Vas a perder una tarde ahí.
• Manda todo a la aplicación y deja que ella conteste. Incluido el 404: al menos será el de quien sabe.
• Reparte por lo que cambia. Lo que cambia con el código, en el código; lo que es del servidor, en el servidor.
• Sirve los archivos con huella desde disco. Sobreviven al despliegue y no gastan tu proceso.
• Busca tus listas duplicadas. Delegar, derivar o invertir, en ese orden.