Resumen

  • 404 conserva varias posibilidades —ausencia temporal, existencia no revelada o estado desconocido— mientras que 410 permite al origen afirmar que el acceso terminó y que la situación probablemente será permanente.
  • La afirmación puede ahorrar consultas y orientar la retirada de enlaces, pero no demuestra un borrado universal ni concede al origen autoridad sobre cachés, archivos o publicaciones independientes.

Dos colas de mantenimiento

Pensemos en un editor con dos colas. A la primera llegan enlaces que fallaron hoy y quizá funcionen mañana. A la segunda deberían llegar los destinos que su propio responsable declaró retirados. Si ambas colas se alimentan con la misma señal, el editor elige entre dos errores: conservar indefinidamente referencias muertas o eliminar demasiado pronto caminos que sólo estaban interrumpidos.

HTTP/1.0 no ofrecía una señal general separada para la segunda cola. RFC 1945, de mayo de 1996, enumeraba 404 entre los códigos reconocidos, pero no 410. Además advertía que 404 no indicaba si la condición era temporal o permanente. El protocolo reflejaba así una realidad modesta: encontrar nada en una petición no equivale a conocer el ciclo de vida del recurso.

Esa modestia sigue siendo necesaria. Un origen puede ocultar la existencia de un recurso prohibido, sufrir un error de publicación o no disponer de un registro fiable de bajas. En todos esos casos, una declaración de permanencia añadiría una certeza inexistente.

Gone convirtió una decisión en evidencia común

La especificación HTTP/1.1 de RFC 2068, publicada en enero de 1997, añadió 410 Gone. La formulación inicial decía que el recurso ya no estaba disponible, que no se conocía una dirección de reenvío y que la condición debía considerarse permanente. Los clientes capaces de editar enlaces debían suprimir la referencia después de obtener aprobación del usuario. Cuando el servidor no pudiera determinar la permanencia, debía usar 404.

La diferencia no estaba en la pantalla de error. Estaba en la procedencia del conocimiento. Un 410 podía apoyarse en la fecha final de una campaña, una decisión editorial, una baja de personal o un estado de configuración que el operador controlaba. El servidor ya no pedía a cada tercero que dedujera una intención a partir del silencio; publicaba su conclusión mediante una semántica compartida.

La aprobación del usuario conservaba una frontera importante. El origen informaba, pero el cliente remoto gobernaba su propia lista. El protocolo facilitaba coordinación entre propietarios distintos, no obediencia automática a una autoridad central.

De una permanencia categórica a una expectativa defendible

La evolución del texto muestra cómo se disciplinó esa conclusión. RFC 2616 explicó que 410 estaba pensado sobre todo para el mantenimiento del Web: comunicaba indisponibilidad intencional y el deseo del propietario de que se retiraran enlaces remotos. Al mismo tiempo, dejaba a su criterio marcar o no todos los recursos desaparecidos y conservar o no la marca.

RFC 7231 y RFC 9110 sustituyeron la idea absoluta por una condición probablemente permanente. El cambio reconoce que una evaluación sólida puede quedar obsoleta. Una página puede restaurarse, una reorganización puede descubrir un destino sucesor y una baja puede resultar accidental.

La definición actual de 404 mantiene un espacio más amplio. Puede significar que no existe una representación actual o que el origen no quiere revelar que existe. No resuelve la duración. Por eso 404 no es un 410 débil ni 410 un 404 más enfático: expresan diferentes niveles de conocimiento y diferentes compromisos del emisor.

Una respuesta negativa también adquiere vida en la caché

Las especificaciones modernas consideran 410 heurísticamente almacenable. RFC 9111 permite que una caché calcule una vida de frescura cuando no recibe una expiración explícita. Mientras esa vida no termine, puede reutilizar la respuesta sin consultar de nuevo al origen.

El efecto operativo es útil. Una URL retirada no obliga a repetir la misma petición desde cada usuario, y los sistemas de mantenimiento observan una señal estable. Pero la estabilidad tiene precio. Si un despliegue asigna 410 por error a una ruta completa, restaurar el contenido en el origen no invalida mágicamente todas las copias frescas. La política debe incluir Cache-Control cuando sea necesario, capacidad de purga y pruebas desde varios puntos de red.

La caché no convierte la respuesta en perpetua. Una frescura heurística tiene límite y después entran en juego validación y reglas de reutilización. Tampoco atestigua la desaparición de datos almacenados: conserva una respuesta sobre acceso, no una auditoría de discos y réplicas.

Retirar acceso no equivale a borrar memoria

El origen controla lo que sirve en su URI. Un sitio remoto controla si conserva un enlace. Un archivo decide qué captura histórica mantiene. Un buscador gobierna su índice. La frase normativa sobre el deseo de retirar enlaces no absorbe esas competencias.

Esta separación es especialmente importante cuando una institución quisiera presentar 410 como prueba de que un hecho dejó de existir. El código no autentica a quien responde, no prueba titularidad, no resuelve una disputa jurídica y no obliga a destruir una copia. Sólo informa del estado que el origen declara para el acceso actual.

También hay alternativas con otra finalidad. Si existe un sucesor legítimo, 301 o 308 puede conservar continuidad mediante una dirección nueva. Si la indisponibilidad se debe a una exigencia legal, 451 aporta una explicación distinta. Si una colección histórica ofrece versiones pasadas, esa disponibilidad puede convivir con un 410 en el origen presente. Elegir bien exige identificar el problema antes de elegir el número.

La autoridad adicional exige una vía de retorno

Una retirada responsable debe responder cinco preguntas: quién decide, qué prueba la probable permanencia, si existe sustituto, cuánto tiempo circulará la respuesta y cómo se recuperará una publicación accidentalmente marcada. También conviene conservar un inventario de referencias de alto valor y registrar qué sistemas internos reaccionan eliminándolas.

El beneficio de 410 es hacer explícita una conclusión que de otro modo cada actor inferiría con reglas distintas. Su riesgo es que esa conclusión provoque acciones independientes difíciles de revertir. El servidor puede dejar de emitir 410 en segundos; un editor externo quizá nunca vuelva a descubrir el enlace que retiró. El diseño histórico de Gone enseña que una señal negativa gana valor al expresar más conocimiento, y gana responsabilidad por la misma razón.

Fuentes y límites

El registro IANA de códigos HTTP enumera actualmente 410 como «Gone» y remite a la sección 15.5.11 de RFC 9110. La evidencia también procede de RFC 1945, RFC 2068, RFC 2616, RFC 7231 y RFC 9111. Estas fuentes no ofrecen un censo actual de navegadores, robots, buscadores, marcos, cachés ni archivos.