Resumen

  • Una respuesta 103 contiene campos que el servidor considera probables, no definitivos. Puede ahorrar latencia al poner en marcha una descarga reversible, pero la respuesta final puede omitirlos, sustituirlos o contradecir la expectativa.
  • La adopción segura exige que el cliente limite el coste de equivocarse. La pista no autentica a su autor, no concede permisos, no fija la política de caché y no autoriza ninguna consecuencia irreversible.

Hay una pequeña paradoja en Early Hints. Para ser útil, el mensaje tiene que llegar antes de que el servidor conozca toda la respuesta. Por la misma razón, no puede tener la autoridad de esa respuesta.

RFC 8297 convierte esa paradoja en un contrato preciso. El servidor puede enviar un estado informativo 103 con campos que probablemente aparecerán en la respuesta final. Mientras espera, el cliente puede evaluar esos campos de manera especulativa. El ejemplo habitual es un Link con relación preload: si una hoja de estilo parece necesaria, el navegador puede empezar a traerla sin esperar a que termine la generación del documento.

El ahorro no nace de una certeza más temprana. Nace de aceptar una incertidumbre acotada. La descarga puede resultar útil, pero también puede sobrar. Un diseño responsable obtiene rendimiento sin presentar la predicción como orden.

Una secuencia, no dos finales

RFC 9110 sitúa las respuestas 1xx antes de una única respuesta final que no pertenece a esa clase. Puede haber cero, una o varias respuestas informativas para la misma solicitud. Carecen de contenido y de tráileres; terminan al acabar su sección de campos. Un cliente debe poder analizarlas aunque no las espere, y un agente de usuario puede ignorarlas.

El 103 ocupa ese espacio intermedio. Indica que es probable que el servidor incluya en el final los campos adelantados. Lo normal es que los repita, pero el estándar contempla que, durante el trabajo restante, descubra que uno era incorrecto o ya no convenía.

Por eso los campos de 103 no reemplazan los campos finales. RFC 8297 añade que, salvo las optimizaciones de rendimiento, su evaluación no debe afectar a la forma en que se procesa la respuesta final. Tampoco son metadatos sobre la propia respuesta 103. No describen una representación intermedia; anticipan parte de otra que todavía no existe del todo.

El texto muestra incluso dos mensajes 103 sucesivos. Entre ambos se anuncian tres enlaces. La respuesta definitiva conserva dos y cambia el tercero. La secuencia no viola ninguna promesa porque nunca hubo promesa: hubo una lista acumulativa de posibilidades.

Esta mecánica desaconseja fusionar las cabeceras tempranas en un objeto presentado internamente como “respuesta provisional”. Ese nombre invita a los consumidores a leerlo como un resultado casi cerrado. Es más seguro conservar cada bloque informativo con su orden y, después, registrar la reconciliación con el final.

La ausencia tampoco manda

Un servidor puede incluir solo algunos de los campos que espera encontrar al final. Cuando manda varios 103, no tiene obligación de repetir lo anterior. El cliente puede combinar lo recibido para anticipar el conjunto, pero no debe interpretar que un campo ausente sea improbable.

La asimetría es importante para la seguridad. Si el primer 103 no contiene una política, una credencial de reto o una directiva de caché, el cliente no obtiene permiso para actuar como si la respuesta final tampoco fuese a contenerla. El canal sirve para afirmaciones positivas y parciales: “esto quizá sea útil”. Su silencio no formula una negación.

También evita que una optimización se convierta en un mecanismo de compromiso. Si el servidor tuviera que enumerar con anticipación todos los campos definitivos, tendría que esperar hasta saberlos. El protocolo preserva el beneficio precisamente porque permite avanzar con información incompleta.

La pregunta operacional, por tanto, no es “¿cuánto confiamos en 103?”. Es “¿qué acciones toleran una predicción incompleta y cuánto estamos dispuestos a perder si falla?”. Esa formulación separa la verdad del mensaje de la prudencia del receptor.

Precargar sigue siendo gastar

La relación preload, descrita dentro del marco de Web Linking, da una semántica reconocible a un enlace. El agente puede prever que su destino ayudará a procesar la representación posterior. No es un verbo imperativo. Nada obliga a todos los clientes a iniciar la misma solicitud ni a dedicar el mismo presupuesto.

Una descarga anticipada tiene efectos reales. Consume datos, abre o reutiliza conexiones, puede tocar otro origen, calienta cachés y añade carga. Según las reglas ordinarias de la plataforma, también puede involucrar información de credenciales. El hecho de recibir el enlace antes no suspende controles de origen, permisos, modo de solicitud o límites de tamaño.

La reversibilidad debe evaluarse por el efecto, no por la etiqueta. Pedir un recurso público, estático y acotado puede admitir cancelación o descarte. Reservar inventario, efectuar un pago, cambiar el estado de una cuenta, aceptar condiciones o divulgar un secreto no se vuelve especulativo en un sentido seguro.

El principio útil es este: Early Hints puede adelantar una operación que ya tenía autorización independiente. Nunca debe ser la fuente de esa autorización.

Incluso una descarga correcta no decide el significado del resultado. La respuesta final podría ser un error, una redirección o un desafío de autenticación. Podría omitir el enlace. Haber obtenido el recurso no demuestra que deba ejecutarse, mostrarse ni incorporarse al documento.

Un intermediario también puede predecir

RFC 8297 no limita todos los indicios tempranos al servidor de aplicación. Describe cómo un intermediario de caché puede generar un 103 a partir de los campos de una respuesta almacenada y ya obsoleta. Después, durante la revalidación, puede reenviar otro 103 y la respuesta final del origen.

El ejemplo ofrece velocidad cerca del usuario, pero rompe una suposición cómoda: lo visto primero quizá no venga del actor que decide al final. Un borde de red puede hacer una estimación basada en el pasado. El origen puede tener información nueva. Ambos mensajes comparten el mismo código sin compartir necesariamente la misma procedencia ni el mismo instante de conocimiento.

Las reglas generales de HTTP obligan al proxy a reenviar respuestas 1xx, salvo cuando él mismo pidió la generación de la informativa correspondiente. Ese deber mantiene la secuencia. No certifica que cada campo sea una declaración directa del origen.

En una arquitectura con CDN, puerta de enlace y aplicación, conviene documentar qué capa sintetiza 103, de qué entrada de caché parte, durante cuánto tiempo y cómo se mide su acierto. El cliente, que puede no disponer de toda esa historia, debe restringir sus acciones a lo que siga siendo seguro bajo procedencia incierta.

La observabilidad debe conservar los actores. Si la plataforma agrupa todos los indicios bajo la etiqueta “servidor”, será imposible distinguir una mala predicción de borde de un cambio de la aplicación.

Equivocarse de final rompe el encuadre

La advertencia de seguridad de RFC 8297 es especialmente concreta para HTTP/1.1. Un cliente defectuoso puede interpretar 103 como respuesta final. En una conexión persistente, las respuestas a solicitudes posteriores podrían quedar asociadas al mensaje anterior. Si la misma conexión transporta solicitudes de distintos orígenes, la confusión abre la puerta a una divulgación entre orígenes.

“Informativo” no es, entonces, una nota decorativa. Es parte de la integridad de la conversación. RFC 9112 exige asociar los mensajes recibidos con la primera solicitud pendiente que todavía no tenga un final no-1xx. Antes de ese final pueden llegar varias respuestas informativas. Alterar esa máquina de estados altera los límites de los mensajes.

RFC 8297 plantea que un servidor podría abstenerse de enviar 103 sobre HTTP/1.1 si no sabe que el cliente trata bien las respuestas informativas. Considera menos probable ese fallo de encuadre en HTTP/2. Allí, las respuestas intermedias son bloques de campos dentro de un flujo, y el bloque que lleva un código informativo no puede cerrar el flujo. HTTP/3 conserva una separación parecida: permite varios 1xx antes del final y prohíbe que tengan contenido o tráileres.

Un transporte moderno evita ciertas ambigüedades de bytes, no las ambigüedades de autoridad. Un cliente puede leer impecablemente HTTP/2 y aun así cometer el error de convertir una predicción en consentimiento. Las dos capas necesitan controles distintos.

La memoria de caché no es la respuesta actual

Una caché que genera un indicio temprano utiliza evidencia histórica. Esa memoria puede ser excelente y aun así estar anticuada. La última página contenía cierto script; la nueva quizá no. La revalidación puede confirmar una parte, cambiar otra o terminar en un estado que no usa ninguna.

RFC 9111 mantiene separadas frescura, validación, almacenamiento y reutilización. Un recurso descargado a raíz de 103 no establece por sí solo la cacheabilidad de la respuesta final. Tampoco convierte el recurso calentado en parte necesaria de la representación.

Las métricas deberían reflejar la secuencia: indicio emitido, recibido, reconocido, descarga iniciada, campo repetido en el final y recurso utilizado. Si se mide únicamente el tiempo hasta el primer byte útil, desaparece del cuadro el coste de predicciones erróneas: datos desperdiciados, solicitudes duplicadas, presión sobre conexiones, exposición de privacidad y carga adicional en el origen.

Es un problema de incentivos. Quien busca una mejor puntuación de rendimiento quizá no pague la tarifa móvil del usuario. La red perimetral puede ganar con más reutilización mientras la aplicación recibe solicitudes que ya no necesitaba. Un presupuesto controlado por el receptor devuelve esos costes al lugar donde pueden observarse.

Coordinación común, riesgo local

El registro de IANA identifica 103 como Early Hints y remite a RFC 8297. El documento fue publicado en 2017 como protocolo experimental de la IETF: tuvo consenso, revisión pública y aprobación del IESG, pero no pertenece al Standards Track. Esta condición impide presentar su uso como obligación universal.

El mínimo compartido, sin embargo, es muy fértil. Todos pueden reconocer que se trata de una respuesta intermedia con campos probables. A partir de ahí, cada entorno escoge su política. Un navegador puede aceptar solo relaciones conocidas. Un cliente corporativo puede prohibir destinos externos. Un dispositivo con datos limitados puede ignorarlo por completo. Un intermediario puede emitirlo únicamente cuando su historial supera un umbral de acierto.

La estructura coincide con la propuesta de Lu Heng: acordar una especificación inicial pequeña, dejar las decisiones futuras cerca de sus consecuencias y permitir una adopción voluntaria informada. El servidor sabe cuánto ha avanzado su cálculo. El intermediario conoce la edad de su evidencia. El cliente conoce su red, sus credenciales y el coste de especular.

No hace falta una oficina central que autorice cada descarga. Tal oficina consumiría parte de la ventaja temporal. Sí hacen falta reglas locales previas: relaciones aceptadas, orígenes permitidos, coste máximo, tratamiento de credenciales y una lista de efectos que nunca pueden empezar por una pista.

Registrar la apuesta y esperar el resultado

Un diseño maduro conserva cada 103 por separado y lo vincula con la solicitud correspondiente. Registra qué campo inició una acción, bajo qué versión HTTP y con qué política. No sobrescribe el historial cuando llega otro indicio.

Después clasifica las apuestas. Las operaciones cancelables y de pérdida limitada pueden recibir presupuesto. Las que crean derechos, transfieren valor, revelan información o modifican estado exigen la autoridad ordinaria y, cuando corresponda, la decisión de una persona.

Al llegar la respuesta final, el cliente reconcilia: qué campos se repitieron, cuáles desaparecieron y cuáles cambiaron; qué descargas siguen siendo útiles; qué coste debe descartarse. La semántica del resultado procede del final, no de la suma de pronósticos.

Por último, mantiene una salida sencilla: ignorar los indicios sin dejar de procesar correctamente la respuesta final. Esa facultad hace posible adaptar la política a una regresión, una red costosa o un intermediario poco fiable sin romper la interoperabilidad.

Early Hints demuestra que compartir antes no obliga a decidir antes. La coordinación gana velocidad cuando el mensaje admite su incertidumbre, el receptor limita su apuesta y la decisión completa conserva el derecho a cerrar la historia.

Fuentes