Resumo

  • A RFC 10036 define o campo HTTP booleano Incremental. O valor verdadeiro pede que intermediários cientes encaminhem conteúdo conforme ele chega; um intermediário que recusa totalmente esse modo deve responder com erro, e não aceitar para depois reter silenciosamente a mensagem completa.
  • O campo não negocia capacidade nem acusa entrega. Um intermediário que não o conhece pode ignorá-lo, requisição e resposta precisam de sinais próprios e um buffer limitado por bytes ou tempo continua permitido. O primeiro avanço ainda precisa ser medido em cada salto.

O salto que entendeu não pode falar pelos demais

O fluxo sem fim do início mostra por que intenção e entrega são registros diferentes. O primeiro proxy conhece a regra e seleciona seu modo incremental. O próximo encontra um campo desconhecido e aplica o comportamento HTTP habitual. Se esse comportamento aguarda o corpo completo, ele pode aguardar indefinidamente sem violar uma regra que nunca interpretou.

Não existe na RFC 10036 uma confirmação positiva de todos os intermediários. Ver o campo saindo da origem prova o pedido do remetente. Ver bytes saindo cedo de um proxy prova apenas aquele salto. Até um status 200 pode aparecer antes de o primeiro conteúdo útil percorrer o restante do caminho.

Essa autoridade também difere de HTTP Priority. Prioridade escolhe quais bytes já elegíveis avançam primeiro sob disputa. Incremental pergunta se o conteúdo começa a cruzar um salto antes da chegada do último byte. Uma resposta pode receber alta prioridade e ficar inteira no buffer seguinte; outra pode fluir cedo com uma parcela modesta de recursos.

Um contrato estreito dá nome a uma escolha antes invisível

O RFC Editor publicou a RFC 10036 na trilha de padrões da IETF em agosto de 2026, após o trabalho do grupo HTTP. A IANA passou a registrar Incremental permanentemente como campo HTTP do tipo Item de Structured Fields e incremental_refused como tipo de erro HTTP Proxy-Status.

A sintaxe é pequena de propósito. ?1 solicita encaminhamento incremental. ?0 mantém o comportamento padrão e pode aumentar a confiança de que o buffer da mensagem toda é aceitável. Valores de outro tipo são ignorados. Parâmetros desconhecidos também são ignorados; eles não transformam o booleano em um diálogo genérico de negociação.

O escopo é uma mensagem HTTP. Se o cliente precisa continuar enviando dados enquanto o servidor começa a responder, requisição e resposta devem declarar o valor verdadeiro separadamente. O campo em uma direção não decide o tratamento do conteúdo na outra.

Quando um intermediário ciente aceita a solicitação, ele deve encaminhar a seção de cabeçalho e fazer o conteúdo avançar continuamente conforme chega, sem esperar o corpo completo. Ainda pode reunir uma seção inteira de cabeçalho ou de trailer. A obrigação rege o modo de encaminhar conteúdo, não apaga todos os limites de processamento.

Recusar com precisão é evidência, não derrota

Algumas funções de segurança precisam examinar a mensagem completa antes de liberar qualquer parte. O remetente não ganha com o campo poder para desligar essa inspeção. A norma dá ao intermediário ciente uma escolha mais honesta: encaminhar cedo ou rejeitar, em vez de aceitar e esconder a espera pelo corpo inteiro.

Para uma incompatibilidade permanente de política de conteúdo, a recomendação é uma resposta 501 com o erro Proxy-Status incremental_refused. O par converte uma paralisação invisível em recusa classificada e ajuda a separar política incompatível de lentidão da origem ou perda no transporte.

Uma limitação temporária de capacidade produz outra resposta. Fluxos longos ocupam conexões e estado concorrente. O intermediário pode aplicar um teto menor a eles para preservar outros usuários. Ao atingir esse teto, a RFC recomenda 429 com Proxy-Status connection_limit_reached.

Essas mensagens não oferecem visão completa do percurso. Um proxy pode omitir detalhes para proteger a topologia; outro pode remover Proxy-Status; trailers podem desaparecer. O registro de incidente deve relacionar a mensagem ao salto emissor, à política, ao estado de capacidade e à telemetria local correspondente.

Incremental não quer dizer buffer zero

Enviar cada fragmento minúsculo como uma operação separada desperdiça CPU, largura de banda e processamento a jusante. A RFC permite, por isso, uma pequena acumulação. A implementação pode liberar o conteúdo quando atinge um limite de bytes ou quando vence um temporizador curto.

A distinção operacional é entre um agrupamento finito e a espera pela conclusão. Um limite de 16 quilobytes junto de 20 milissegundos cria uma faixa mensurável. “Até o corpo terminar” não cria nenhuma, principalmente quando a resposta pode permanecer aberta por horas.

O ?1 não revela os limites e não exige emissão imediata de pacote. Também não reserva banda, ignora controle de fluxo ou substitui controle de congestionamento. Biblioteca HTTP, proxy, TLS, kernel e transporte podem introduzir seus próprios atrasos depois da decisão da aplicação.

O objetivo de serviço útil mede bytes e tempo entre a entrada de um lado do salto e a primeira saída, além da cadência seguinte. Ele especifica tamanho, ritmo dos eventos, carga simultânea e falhas. Dizer “buffer desligado” não substitui uma distribuição observada de latência.

O intermediário desinformado permanece como fronteira dura

Quem entende o campo deve falhar se decidir não atender ao modo pedido. Quem não entende não consegue obedecer a essa exigência e pode ignorar o campo, armazenando a mensagem como antes.

Por isso a especificação aponta para conhecimento prévio ou sondagem específica do recurso. O campo coordena implementações compatíveis; não descobre universalmente capacidade. Um teste bem-sucedido numa URL, num POP, numa versão HTTP ou numa rota não serve para sempre em outro contexto.

Os caminhos mudam. Um CDN adiciona inspeção, distribui tráfego entre gerações, migra o cliente para outro gateway ou negocia outra versão HTTP a montante. Um teste origem-borda pode perder um buffer entre borda e cliente. Uma resposta pequena que termina sempre pode esconder exatamente a espera infinita que afeta o fluxo real.

Evidência de capacidade precisa de tempo e caminho. O registro deve guardar seleção DNS e de rota, identidades de proxies, versões HTTP, revisões de configuração, preservação do campo, limites, instante do primeiro cabeçalho e do primeiro conteúdo, cadência contínua e a observação final do cliente.

Fluxos longos e bidirecionais expõem falhas diferentes

Server-Sent Events é o caso mais claro na resposta, pois o buffer da mensagem completa vira espera indefinida. A aplicação deve provar que os eventos emergem no ritmo esperado por cada caminho de produção suportado, e não apenas que os cabeçalhos chegaram.

Chunked Oblivious HTTP motiva os dois sentidos: o cliente pode continuar enviando enquanto o servidor já começa a responder. Cada mensagem precisa do seu sinal. O relatório do IESG diz que esse trabalho depende do campo incremental e observa poucas implementações em produção. Isso é aviso para medir suporte, não permissão para enfraquecer a semântica.

A RFC 10036 também indica que Extended CONNECT costuma ser mais coerente com a arquitetura HTTP para protocolos bidirecionais. HTTP/2 e HTTP/3 definem mecanismos Extended CONNECT para WebSockets. Usar requisição-resposta comum com conteúdo incremental deve ser uma decisão explícita de compatibilidade, não a suposição de que um campo transforma qualquer cadeia em túnel.

A cadeia de evidência termina no avanço observado

O remetente responde pela intenção colocada na mensagem. Cada intermediário responde por suporte, inspeção, capacidade e limites de buffer. O responsável pela aplicação decide se o caminho medido atende ao produto e qual alternativa permanece segura.

A cadeia começa com identidade e direção da mensagem, o booleano realmente analisado e software e configuração de cada salto. Segue pela preservação do campo, modo local, limites em bytes e tempo, instantes de entrada e saída, recusas e Proxy-Status confiáveis. Termina no primeiro evento visto pelo cliente, cadência posterior, estado da aplicação e impacto sobre recursos.

Uma camada não deve ser promovida à seguinte. Campo registrado não prova suporte. Suporte não prova uso nesta requisição. Saída de um salto não prova entrega ponta a ponta. Primeiro byte não prova continuidade segura. A nova norma torna uma decisão expressável; só evidência operacional mantida demonstra para onde os bytes foram.

Fontes