Resumo

  • Incremental: ?1 registra a intenção do remetente para uma mensagem HTTP: começar a encaminhar o conteúdo antes de receber o corpo completo. Requisição e resposta são mensagens separadas e precisam declarar a intenção em cada direção.
  • Se um intermediário entende o campo e recusa de forma definitiva o encaminhamento incremental do corpo, deve responder com erro, não armazenar tudo em silêncio. Inspeção incompatível usa 501 com incremental_refused; limite temporário de concorrência usa 429 com connection_limit_reached.
  • Isso não garante streaming na rota inteira. Um salto que desconhece o campo pode ignorá-lo, e um salto compatível pode usar buffer limitado por tempo ou bytes. A prova precisa unir direção, reconhecimento por salto, política, limites, contexto do erro e latência medida.

O caso crítico não é uma conexão encerrada. É a conexão que permanece aberta enquanto o servidor já produz dados e o cliente não recebe nada. Em uma troca bidirecional, o cliente pode continuar enviando e aguardar uma resposta antecipada; o servidor responde antes do fim da requisição; um proxy segura uma das mensagens até completá-la. O sistema entra em espera mesmo sem uma falha tradicional de transporte.

Publicada em agosto de 2026 como Padrão Proposto do IETF, a RFC 10036, Incremental Forwarding of HTTP Messages, foi escrita por Kazuho Oku, Tommy Pauly e Martin Thomson. O perfil do IETF preservado em 31 de agosto lista quatro RFCs para Oku. A página de autor da Fastly o apresenta como Principal OSS Engineer e autor de H2O, quicly e picoTLS. O contexto mostra uma trajetória em software de rede de alto desempenho; não converte autoria coletiva em invenção individual nem comprova qualquer implantação.

Uma intenção por mensagem

Incremental é um Item de Structured Fields. Somente Boolean é válido; outro tipo é ignorado. ?1 pede encaminhamento incremental. ?0 explicita o comportamento comum em que o intermediário pode armazenar a mensagem completa.

O campo se aplica à mensagem, não à conexão. Marcar a requisição não marca a resposta. Se a aplicação depende das duas direções, ambas precisam do campo. Essa separação impede que um teste de download seja usado como prova para upload progressivo.

Ao receber ?1, um intermediário compatível não deveria manter o corpo inteiro. Deveria transmitir a seção de cabeçalhos e encaminhar continuamente os bytes do conteúdo. Ainda pode armazenar cabeçalhos e trailers completos. Para um protocolo realmente bidirecional, a própria RFC observa que Extended CONNECT costuma se alinhar melhor à arquitetura HTTP.

A recusa deixa de se esconder no sucesso

Quando um salto entende o campo e decide recusar integralmente o encaminhamento incremental do corpo, precisa gerar um erro. Entregar tudo mais tarde não preserva a propriedade temporal solicitada.

Um erro permite ação: mudar a rota, adotar outro protocolo, reduzir a função, tentar depois ou comunicar indisponibilidade. O buffer silencioso mantém a transação aparentemente saudável e pode tornar inútil um console, um feed de eventos ou uma resposta antecipada.

A regra é estreita. Nem todo atraso é recusa, e o intermediário não precisa enviar cada byte imediatamente. O que se torna visível é uma decisão deliberada de um participante. A prova segundo a primazia do código em execução envia fragmentos identificáveis pela rota real, registra quando cada salto controlado recebe e encaminha e verifica se o contexto de erro chega a quem decide.

Segurança permanente e capacidade temporária

Alguns intermediários precisam ver o corpo inteiro para inspecioná-lo. Essa função é incompatível com entrega incremental. A RFC recomenda 501 Not Implemented com incremental_refused no Proxy-Status. Repetir sem mudança tende a produzir o mesmo resultado; rota, inspeção, recurso ou protocolo precisam ser reconsiderados.

Outro caso é o limite de concorrência. Trocas incrementais podem ocupar recursos por mais tempo. O intermediário pode reservar um pool menor para elas e proteger requisições comuns. Quando o pool esgota, a recomendação é 429 Too Many Requests com connection_limit_reached.

Aqui a compatibilidade pode existir e a vaga estar temporariamente indisponível. Backoff, prioridade, admissão e capacidade são respostas adequadas. Tratar os dois resultados como “streaming falhou” elimina a diferença que orienta a correção.

O status isolado não basta. 501 e 429 têm outros usos. O registro precisa ligar Proxy-Status, salto responsável, recurso, política e horário. Se algum intermediário não participa, sua ausência permanece uma lacuna.

O salto desconhecido continua opaco

Um intermediário que não conhece o campo não muda seu comportamento. Um que o reconhece, mas não oferece suporte, também pode armazenar. Por isso, não receber erro não prova suporte de ponta a ponta.

O salto compatível que recusa é mais observável do que o salto ignorante que atrasa e deixa passar. Conhecimento prévio testado pode reduzir a incerteza em rotas controladas. Caso contrário, a RFC sugere sondar recursos individuais.

O recorte por recurso evita uma certificação falsa. Um mesmo domínio pode usar caminhos e políticas diferentes por região, tipo de corpo, cliente ou carga. Uma sonda bem-sucedida prova as condições daquele momento, não a marca para sempre.

O limite de agência é igualmente importante: o remetente declara intenção; cada intermediário controla segurança, capacidade e encaminhamento; o endpoint interpreta. Nenhuma ponta pode prometer o comportamento de software que não controla.

Buffer limitado também altera o SLO

Mesmo um salto compatível pode reter uma pequena quantidade para eficiência e proteção contra muitos fragmentos mínimos. Ele pode usar limites de bytes e de tempo, mas precisa encaminhar quando um deles for atingido; não pode reter indefinidamente.

Assim, suporte não equivale ao orçamento de latência da aplicação. Um limite de bytes irrelevante para uma resposta volumosa pode atrasar um feed esparso. Um temporizador curto para uma pessoa pode ser longo para controle entre máquinas.

Os limites, a classe e a ocupação devem ter versão e ser ligados ao tempo até o primeiro byte. O padrão fornece a especificação inicial mínima; elegibilidade do recurso, inspeção, capacidade, SLO e fallback continuam decisões locais.

Construir o recibo do caminho ao resultado

Registre cliente, servidor, recurso, versão, identificador e direção. Preserve o valor do campo, a validação Boolean e o componente que o definiu. Para cada intermediário controlado ou participante, mantenha segmento de protocolo, reconhecimento, regra de inspeção, política de corpo/cabeçalhos/trailers, limites de tempo e bytes, pool de concorrência, ocupação e prioridade.

Ligue o resultado: status HTTP, membro Proxy-Status, tipo de erro, salto responsável e horários do primeiro e último byte recebido e encaminhado. Classifique entrega incremental aceitável, degradação por buffer limitado, recusa estrutural, recusa temporária, provável buffer silencioso e evidência inconclusiva.

Por fim, preserve decisão e dono: nova rota, outro protocolo, tentativa posterior, capacidade, exceção de segurança, modo reduzido e prazo de correção. Não é preciso guardar corpos sensíveis; identificadores seguros, versões de política e tempos costumam bastar.

Uma lacuna deve continuar sendo lacuna. Salto desconhecido, Proxy-Status removido ou direção não testada não podem virar um selo de conformidade.

Fontes