Resumen

  • RFC 10036, publicado en la vía de estándares del IETF en agosto de 2026, registra el campo HTTP booleano Incremental. ?1 solicita a cada intermediario compatible que reenvíe el contenido de ese mensaje conforme llega; no impone el modo a quien desconoce el campo ni certifica un flujo de extremo a extremo.
  • El intermediario compatible debería enviar la sección de encabezados y liberar continuamente el contenido, aunque puede retener encabezados, trailers y una cantidad pequeña y acotada de bytes. Si entiende la petición y la rechaza por completo, debe responder con error en lugar de esconder el rechazo tras un buffer de mensaje entero.

La escena decisiva ocurre antes de que alguien vea un error. Un servidor empieza una respuesta que durará una hora. Escribe el primer registro a los cien milisegundos. El balanceador lo reenvía. Una pasarela de seguridad, configurada para aprobar solo cuerpos completos, espera la hora entera. La aplicación cliente mantiene la conexión abierta y su temporizador de red no vence. Para el usuario, sin embargo, el servicio está mudo.

La disponibilidad de la conexión, el éxito de las escrituras del origen y la ausencia de un 5xx no demuestran el tiempo de entrega. Cada indicador describe la autoridad local de un componente.

RFC 10036 fue diseñado para exponer ese desacuerdo. RFC 9110 permite que un receptor procese las partes de un mensaje conforme llegan, pero también reconoce que los intermediarios pueden almacenarlo o retrasarlo. El buffer puede mejorar eficiencia, disponibilidad, control de acceso, inspección o transformación. El problema aparece cuando la aplicación necesita una salida antes de que el mensaje termine.

Los Server-Sent Events muestran el caso unilateral: la respuesta permanece abierta para emitir eventos y un buffer completo puede no vaciarse nunca. El borrador de Chunked Oblivious HTTP Messages, citado de forma informativa por RFC 10036, muestra el bloqueo bilateral: el servidor puede querer responder mientras el cliente todavía envía, de modo que almacenar por completo cualquiera de los dos mensajes impide el progreso de ambos.

El estándar no declara que todo HTTP sea un stream. Define un lenguaje preciso para los mensajes que sí necesitan avanzar y una conducta para quienes reconocen ese lenguaje.

Cuatro entradas al mismo parser

Incremental es un Item de Structured Field Values for HTTP. Solo admite valores booleanos. La forma verdadera, Incremental: ?1, pide reenvío incremental. La forma falsa, Incremental: ?0, conserva el régimen ordinario en el que el intermediario puede esperar el mensaje entero; expresarlo puede darle mayor seguridad para elegir el buffer.

Si el campo no aparece, RFC 10036 no recibe ninguna petición. Si aparece con otro tipo estructurado, el destinatario lo ignora. Por eso no se puede traducir todo a una variable de observabilidad llamada “streaming sí/no”. ?1 es intención; ?0 no obliga a retener; ausencia no es rechazo; una entrada inválida no es una negociación fallida.

El registro IANA de nombres de campos HTTP ya presenta Incremental como permanente, con tipo Item y referencia a RFC 10036. Esa inscripción evita colisiones y fija la gramática. No dice qué proveedor, ruta o recurso ejecuta la semántica.

Cada dirección negocia su propio mensaje

Una solicitud larga puede avanzar hacia el origen mientras una respuesta temprana vuelve hacia el cliente. Para pedir comportamiento incremental en ambos sentidos, ambos mensajes deben llevar ?1. El campo de la solicitud no se hereda en la respuesta. Tampoco puede un encabezado de respuesta rescatar bytes de solicitud que un salto anterior ya decidió acumular.

La separación afecta a la prueba. La ruta de ida puede incluir un filtro de carga y la de vuelta un transformador. Pueden usar conexiones, versiones HTTP y políticas distintas. Un reintento puede cambiar de edge. Registrar “sesión streaming” borra precisamente la información necesaria para saber quién retuvo qué.

Cuando un intermediario compatible recibe ?1, no debería esperar el cuerpo completo. Debería reenviar la sección de encabezados y continuar enviando bytes de contenido conforme aparecen. Sin embargo, el campo regula el contenido. El intermediario puede almacenar la sección completa de encabezados y la de trailers. La norma no promete una equivalencia uno a uno entre llamadas write, frames, paquetes y lecturas del cliente.

También alcanza a las API HTTP. Si una biblioteca introduce un buffer pese a tener un mecanismo para reducirlo, debería reaccionar al campo. Pero una API con lectura progresiva solo habla de su propio límite. No demuestra que un CDN anterior haya vaciado pronto, ni que el consumidor convierta cada fragmento en un evento útil.

El rechazo consciente no puede fingir éxito

RFC 10036 establece una diferencia esencial entre no comprender y contradecir. Un intermediario que desconoce el campo puede ignorarlo y seguir almacenando. Uno compatible puede atenderlo. Uno que lo entiende puede negarse. Si decide negarse por completo, debe generar una respuesta de error; no puede aceptar la petición, guardar todo el cuerpo y liberarlo al final como si hubiera cumplido.

Esta regla no convierte la adopción en universal. Hace auditable una decisión que de otro modo se manifestaría solo como latencia misteriosa.

La incompatibilidad de seguridad es el ejemplo permanente. Un WAF que necesita el cuerpo completo para declarar seguro el contenido no puede entregarlo antes de decidir. RFC 10036 recomienda 501 Not Implemented junto con Proxy-Status y el error incremental_refused.

El registro IANA de HTTP Proxy-Status asigna a incremental_refused el código recomendado 501 y reserva su generación a intermediarios. La señal ubica la negativa en la cadena; no prueba que el servidor de origen haya rechazado la operación de negocio.

La falta transitoria de capacidad merece otro camino. Una solicitud incremental y duradera puede ocupar conexiones y slots durante mucho más tiempo que una solicitud ordinaria. El intermediario puede imponerle un techo de concurrencia más estricto para mantener capacidad disponible. Al llegar al techo, RFC 10036 recomienda 429 Too Many Requests, definido en RFC 6585, con connection_limit_reached. Seguridad estructural y saturación temporal no deben converger en una misma alarma ni en la misma política de reintento.

La norma permite agrupar gotas

Vaciar cada byte de inmediato puede multiplicar paquetes, interrupciones y trabajo de planificación. Una fuente hostil podría producir fragmentos diminutos para consumir recursos de los intermediarios. Por eso la entrega incremental admite un pequeño buffer por cantidad de bytes o por tiempo.

El límite es que el buffer no sea indefinido: al alcanzar el umbral temporal o de tamaño, los datos tienen que avanzar. La operación debe reconocer el costo. Un umbral alto reduce overhead y aumenta el retraso; uno bajo mejora la respuesta y puede dañar eficiencia y capacidad.

De ahí que el tiempo al primer byte sea insuficiente. Un sistema puede vaciar la primera porción enseguida y luego acumular durante diez segundos. También puede entregar bytes que todavía no completan un objeto comprensible por la aplicación. La cadena debe medir el final de encabezados, el primer contenido, el progreso periódico, el mayor silencio, el primer evento útil, los trailers y el cierre.

Esas marcas necesitan ubicación. La hora en que el origen escribe, la hora en que un proxy envía y la hora en que el cliente consume no son intercambiables. Una métrica agregada puede convertir un buffer intermedio en “tiempo de aplicación” y dejar al propietario del control fuera de la investigación.

Un testigo útil puede ser incompleto

RFC 9209 define Proxy-Status para que los intermediarios describan cómo manejaron una respuesta y su solicitud. Los miembros aparecen en orden desde el más cercano al origen hasta el más cercano al agente de usuario. El campo puede incluir errores, siguiente salto o estado recibido; en ciertos fallos tardíos de streaming, parte de la información solo cabe en trailers.

La visibilidad no es obligatoria. Un operador puede publicar el campo solo bajo depuración o autenticación y ocultar datos de topología. Los parámetros son opcionales. La propia RFC advierte que el contenido no está verificado: el intermediario puede afirmar que actuó de una manera aunque la ejecución no coincida.

Por tanto, incremental_refused presente es evidencia valiosa de una negativa declarada. Su ausencia no certifica nada. El salto puede ser antiguo, la política puede suprimir el diagnóstico o el trailer puede desaparecer. La conclusión requiere reconciliar el campo con la entrada del parser, la política, los umbrales y las marcas de bytes en ambos lados.

Una petición de flujo no decide si se necesita un túnel

Con ?1 en solicitud y respuesta, el mecanismo facilita un canal de bytes bidireccional y el reenvío de una respuesta antes de acabar la solicitud. Aun así, RFC 10036 señala que Extended CONNECT en HTTP/2 y Extended CONNECT en HTTP/3 suelen ser arquitectónicamente más coherentes para protocolos bidireccionales.

Un feed progresivo, una representación grande y un protocolo dúplex no comparten el mismo contrato. El último necesita elegir subprotocolo, administrar vida y control de flujo en dos sentidos y tratar interrupciones como parte normal del canal. Simularlo mediante dos cuerpos extensos puede parecer compatible hasta que los clientes, excepciones de seguridad y SDK queden atados a la decisión.

El conocimiento previo o una sonda por recurso puede demostrar soporte en una ruta concreta. No crea una propiedad permanente: cambian las rutas, las versiones, las reglas y la carga. La consulta de erratas de RFC 10036 no mostraba registros coincidentes el 30 de agosto de 2026; esa es una fotografía del registro, no una promesa sobre el futuro.

Construir un expediente de liberación

El expediente debe conservar recurso, dirección, identificador, traza, intento, versión HTTP, conexión y ruta; el valor exacto recibido y reenviado; el resultado del parser; versiones de soporte y política; admisión de capacidad; umbrales de tiempo y bytes; recepción y emisión de encabezados y contenido; mayor intervalo; primer evento útil; trailers, fin, cancelación, reset, estado, Proxy-Status y un control sin campo o con ?0.

Las pruebas tienen que incluir una fuente de un byte, eventos lentos, ráfagas, backpressure, un cuerpo interminable, inspección integral, techo de concurrencia, cancelación, retry y cambio de camino. Una demostración que solo usa una respuesta rápida y conocida no explora el motivo por el que existe el estándar.

La primacía del código en ejecución de Heng Lu coloca la autoridad en lo que las implementaciones hicieron, no en lo que una cabecera o documento anunció. Su patrón de especificación inicial mínima, decisión futura localizada y adopción voluntaria explica por qué un bit común puede coordinar sin centralizar políticas de buffer y seguridad. Su análisis de capacidad técnica frente a control práctico completa el límite: el emisor puede expresar técnicamente la intención, pero cada intermediario conserva el control práctico de su salida.

La cabecera puede pedir. Solo la cronología de los bytes puede demostrar que el camino respondió.