Resumen

  • Incremental: ?1 pide que los intermediarios comiencen a reenviar un mensaje antes de recibirlo completo. Es una señal por mensaje: petición y respuesta deben declararla por separado.
  • Cuando un salto entiende el campo y se niega de plano al reenvío incremental del cuerpo, debe responder con error en lugar de almacenarlo entero en silencio. 501 con incremental_refused describe incompatibilidad de inspección; 429 con connection_limit_reached, presión de concurrencia.
  • El campo no certifica toda la ruta. Un intermediario que lo desconoce puede ignorarlo, y uno compatible puede usar un búfer limitado. La operación necesita un recibo que una intención, dirección, salto, política, umbrales, respuesta y latencia.

La escena operativa es conocida: el servidor ya produce fragmentos, la conexión sigue abierta y el cliente no muestra nada. El tablero de red no registra una caída. Minutos después llega el contenido completo. El resultado HTTP puede ser válido, pero la propiedad que hacía útil a la aplicación —recibir pronto los primeros bytes— desapareció en un intermediario.

En intercambios bidireccionales, almacenar el mensaje completo puede crear una espera circular. El cliente continúa enviando mientras espera una respuesta temprana; el servidor responde antes de que termine la subida; el proxy retiene una de las dos corrientes. Ningún actor rompe necesariamente las reglas generales de HTTP, pero el protocolo de aplicación deja de avanzar.

RFC 10036, Incremental Forwarding of HTTP Messages, se publicó en agosto de 2026 como estándar propuesto del IETF. Sus autores son Kazuho Oku, Tommy Pauly y Martin Thomson. El perfil del IETF guardado el 31 de agosto de 2026 enumera cuatro RFC para Oku; Fastly lo presenta como Principal OSS Engineer y autor de H2O, quicly y picoTLS. Es un contexto relevante para su trabajo en software de red, no una atribución de invención individual ni una prueba sobre los productos que atraviesa cada petición.

La intención vive en cada mensaje

Incremental adopta el formato Item de Structured Fields y solo acepta un booleano. Un valor de otro tipo se ignora. Con ?1, el emisor pide reenvío incremental; con ?0, expresa el comportamiento normal, que puede incluir almacenamiento completo.

La unidad no es la conexión ni el endpoint, sino el mensaje. Marcar la petición no marca la respuesta. Si la aplicación requiere subida y bajada incrementales, ambas deben llevar el campo. Esta separación impide que una prueba exitosa del consumo de respuesta se convierta en una afirmación no comprobada sobre el envío de la petición.

Un intermediario compatible debería enviar la sección de cabeceras y después ir reenviando los bytes del contenido a medida que llegan. Puede seguir almacenando las cabeceras y los trailers completos. El campo no exige que todas las piezas de la representación HTTP se comporten igual.

Con la señal en las dos direcciones puede formarse un canal de bytes bidireccional, aunque la propia RFC considera Extended CONNECT generalmente más coherente con la arquitectura HTTP para protocolos de ese tipo. La elección entre ambos no se resuelve con una etiqueta comercial de “streaming”. Depende de la ruta y del patrón de interacción.

Rechazar es mejor que simular éxito

El avance más importante aparece cuando el intermediario entiende la petición, pero no quiere cumplirla. Si decide rechazar de plano el reenvío incremental del cuerpo, tiene que generar una respuesta de error. No puede acumular todo el mensaje y entregarlo después como si hubiese preservado la propiedad solicitada.

El error es operativo. Permite elegir otro camino, usar un protocolo distinto, reducir la función o comunicar una indisponibilidad. El silencio produce una espera cuyo dueño es difícil de localizar. El mensaje puede terminar correctamente cuando ya no tiene valor para el usuario.

La obligación no convierte cualquier demora en incumplimiento. Tampoco prohíbe cada microbúfer. Identifica una decisión consciente de un salto que participa en el mecanismo. Por eso una prueba en el sistema real debe provocar el rechazo y comprobar que el código, Proxy-Status y salto responsable sobreviven hasta el cliente o servidor que tomará la decisión.

El principio de código en ejecución exige medir el primer byte, no solo revisar una configuración. Fragmentos identificables, marcas de tiempo por salto y condiciones controladas pueden demostrar qué hizo la ruta. Una captura del campo en el origen solo demuestra que el origen lo emitió.

Dos motivos que exigen remedios diferentes

Hay intermediarios que necesitan el cuerpo completo para inspeccionarlo antes de reenviarlo. Esa función de seguridad es incompatible con la entrega incremental. RFC 10036 recomienda responder 501 Not Implemented y añadir el error Proxy-Status incremental_refused.

Es un conflicto duradero mientras no cambie la inspección, la ruta, el recurso o el protocolo. Reintentar sin modificaciones suele repetirlo. La decisión pertenece a arquitectura y seguridad: dónde inspeccionar, qué intercambio puede quedar exento y qué alternativa conserva la protección.

El segundo motivo es la capacidad. Un intercambio incremental puede ocupar recursos durante más tiempo. Un proxy puede imponer un límite más estricto a esas peticiones para reservar servicio a las demás. Al llegar al límite, la recomendación es 429 Too Many Requests con connection_limit_reached en Proxy-Status.

Ahora la compatibilidad puede existir y faltar solamente una plaza. Espera, admisión, prioridad, ampliación de capacidad o degradación controlada son respuestas razonables. Confundir esta presión temporal con una incompatibilidad permanente conduce a sobredimensionar o rediseñar el componente equivocado.

Ni 501 ni 429 bastan por sí solos. Ambos estados tienen usos más amplios. El recibo debe conservar el contexto Proxy-Status, el intermediario, la política, el recurso y el momento. Si algún salto no informa, esa ausencia sigue siendo una brecha, no una confirmación.

La ruta desconocida no firma el contrato

Los intermediarios que no conocen el campo no cambian su conducta. Incluso los que lo reconocen sin implementarlo pueden almacenar el mensaje. Por eso la falta de error no equivale a soporte de extremo a extremo.

Un salto compatible que rechaza deja una pista. Uno ajeno al mecanismo puede añadir retraso sin emitirla. Ese contraste explica por qué la RFC habla de conocimiento previo o de sondeos para recursos concretos. El soporte depende del camino que realmente recorre ese recurso y puede variar con la región, la política, el tipo de contenido o la carga.

Un sondeo exitoso es una observación fechada. No convierte a una marca, un dominio o una red en compatible para siempre. Debe repetirse después de cambios de ruta, proxy, seguridad o capacidad, y debe distinguir petición de respuesta.

El límite de agencia también evita exageraciones. El emisor expresa una intención; cada intermediario mantiene su decisión de seguridad y recursos; el receptor decide qué hacer con el resultado. Ningún endpoint puede prometer el comportamiento de software que no controla.

El búfer pequeño también cuenta

La RFC admite cierta acumulación para evitar el coste de reenviar cantidades diminutas. Un intermediario puede usar un máximo de bytes o de tiempo. Cuando se alcanza uno de los dos, necesita reenviar; no puede retener indefinidamente.

Ese margen separa la conformidad de la utilidad. Un umbral de bytes puede ser irrelevante para una descarga rápida y desastroso para una señal escasa. Un temporizador corto para una persona puede ser largo para una interacción máquina a máquina. El contrato local debe fijar el presupuesto de primer byte y probarlo.

Los umbrales, la clase de servicio y el nivel de ocupación tienen que quedar versionados. De otro modo, una regresión de latencia parece misteriosa aunque solo haya cambiado una política. La especificación inicial mínima pertenece al IETF; el operador conserva la obligación de documentar y observar sus elecciones locales.

Un recibo que atraviese la ruta

Primero se identifica la transacción: cliente, servidor, versión, recurso, mensaje y dirección. Se conserva el valor exacto del campo, su validez booleana y el componente que lo añadió. Después se enumeran los saltos conocidos: protocolo, reconocimiento, regla de inspección, política de cuerpo/cabeceras/trailers, límites de tiempo y bytes, pool de concurrencia y ocupación.

El resultado une estado HTTP, miembro Proxy-Status, tipo de error, salto responsable y marcas de tiempo de recepción y reenvío del primer y último byte. También registra el resultado para la aplicación: entrega aceptable, degradación por búfer acotado, rechazo permanente, rechazo temporal, almacenamiento silencioso probable o evidencia inconclusa.

Por último se conserva la decisión: reintento, otra ruta, otro protocolo, capacidad, excepción de seguridad, modo reducido, dueño y fecha de reparación. No hace falta copiar cuerpos sensibles. Identificadores seguros, tiempos y versiones de política pueden reconstruir el camino sin crear un archivo de contenido.

La incertidumbre debe permanecer visible. Si no se conoce un salto, si se perdió Proxy-Status o si solo se probó una dirección, el recibo lo declara. Esa disciplina evita que un simple campo termine convertido en una promesa que nunca hizo.

Fuentes