Resumo

  • Publicada na trilha de padrões da IETF em agosto de 2026, a RFC 10036 define o campo HTTP booleano Incremental. O valor ?1 pede que intermediários compatíveis encaminhem o conteúdo à medida que ele chega; não transforma o caminho inteiro em um tubo comprovadamente contínuo.
  • Um intermediário que oferece suporte deve enviar a seção de cabeçalhos e avançar o conteúdo sem esperar a mensagem completa. Pode manter cabeçalhos, trailers e uma pequena quantidade de conteúdo em buffer. Se entende o pedido e o recusa de forma absoluta, precisa responder com erro, em vez de esconder a recusa atrás de um sucesso tardio.

Considere uma resposta de eventos que deveria permanecer aberta por horas. A origem entrega um evento a cada segundo. O primeiro proxy repassa cada fragmento, mas o gateway de inspeção só autoriza uma resposta depois de examinar o corpo completo. Como “completo” talvez nunca aconteça, nenhuma regra acusa falha: a origem escreveu, o gateway está esperando e o cliente está conectado. O produto, porém, parou.

É possível que todos os painéis locais estejam corretos e a conclusão global esteja errada. O campo Incremental serve para reduzir essa ambiguidade. Ele carrega a intenção do remetente e estabelece uma obrigação para quem declara entender o mecanismo. Não transfere ao remetente a autoridade prática sobre cada implementação do percurso.

A RFC 10036 parte da liberdade já prevista pela semântica HTTP: um destinatário pode processar partes enquanto chegam, mas um intermediário também pode adiar o encaminhamento ou armazenar o corpo inteiro. Há bons motivos para isso — inspeção, transformação, eficiência e proteção de capacidade. Há também aplicações em que esse comportamento destrói a própria utilidade da resposta.

Os Server-Sent Events oferecem o caso unilateral mais claro. A resposta permanece aberta para entregar eventos sucessivos; esperar pelo seu fim equivale a não entregar evento nenhum. O rascunho de Chunked Oblivious HTTP Messages, citado pela RFC 10036 como trabalho em andamento, expõe o impasse de mão dupla: se a resposta precisa começar antes do término da requisição, o buffer integral em qualquer direção pode bloquear as duas.

Quatro entradas parecidas, quatro significados diferentes

Incremental é um Item de Structured Field Values for HTTP e só admite um booleano. A forma verdadeira é:

Incremental: ?1

Ela solicita encaminhamento incremental do conteúdo. A forma falsa, Incremental: ?0, mantém o padrão do HTTP, no qual o intermediário pode esperar pela mensagem completa; a declaração explícita pode até aumentar a confiança nessa escolha. A ausência do campo não faz pedido algum segundo a RFC. Um valor de outro tipo é ignorado.

Essas situações não podem virar um único estado “streaming ligado/desligado”. ?1 não comprova execução ponta a ponta. ?0 não ordena armazenamento integral. Ausência não é recusa. Sintaxe inválida não é um voto contra o mecanismo. Primeiro é preciso saber se cada receptor reconheceu o campo, como o interpretou e qual política executou.

O registro de campos HTTP da IANA agora contém Incremental como nome permanente, de tipo estruturado Item. O registro estabiliza o nome e a gramática. Não revela se um WAF instalado hoje compreende a regra nem em que momento um byte saiu de sua fila.

A unidade de decisão é a mensagem

O campo não se aplica automaticamente à sessão. Se a aplicação precisa que o corpo da requisição avance para a origem e que uma resposta antecipada volte antes de a requisição terminar, ambas as mensagens precisam carregar seu próprio ?1. Um pedido verdadeiro na ida não autoriza a inferência de um pedido verdadeiro na volta.

Essa separação importa porque os dois sentidos podem atravessar adaptadores, políticas e restrições diferentes. Uma nova tentativa pode escolher outra conexão de origem. Um balanceador pode aceitar o fluxo de resposta enquanto um scanner retém a requisição. Registrar apenas “streaming=true” no nível da transação apaga exatamente o ponto que deve ser investigado: direção, mensagem, tentativa e rota.

Um intermediário compatível que recebe ?1 deve encaminhar a seção de cabeçalhos e liberar continuamente os bytes de conteúdo conforme chegam, sem aguardar o corpo inteiro. A RFC delimita a promessa: o campo trata do conteúdo. Ainda é permitido reunir a seção completa de cabeçalhos e a seção completa de trailers. Portanto, incremental não significa que todo octeto deve ser imediatamente convertido em um pacote.

O mesmo raciocínio vale dentro das APIs. Uma biblioteca pode expor leitura progressiva e ainda receber dados de um proxy que acumulou o corpo. Um proxy pode encaminhar cada lote rapidamente e o framework da aplicação pode só entregar o resultado depois de preencher seu próprio buffer. Cada limite conserva poder prático sobre a cadência.

Quem entende e não pode cumprir precisa dizer “não”

A contribuição de governança mais forte da RFC 10036 aparece na recusa. Se um intermediário entende o campo e decide não encaminhar incrementalmente, deve gerar uma resposta de erro. Ele não pode aceitar a mensagem, armazená-la por inteiro e apresentá-la mais tarde como se o pedido tivesse sido atendido.

Isso separa desconhecimento, suporte e oposição. Um componente antigo pode ignorar um campo desconhecido. Um componente compatível pode cumprir. Um componente consciente pode recusar. O padrão não consegue obrigar software que nunca o implementou; consegue impedir que a recusa deliberada se esconda em uma resposta aparentemente normal.

Há uma incompatibilidade permanente quando a política de segurança exige examinar todo o corpo antes de liberar qualquer parte dele. Nesse caso, a RFC recomenda 501 Not Implemented com o erro incremental_refused em Proxy-Status. O registro IANA de Proxy-Status associa esse erro a 501 e diz que a resposta é gerada apenas por um intermediário. A evidência aponta para uma decisão no caminho, não necessariamente para rejeição da operação pela origem.

Escassez temporária é diferente. Fluxos longos ocupam conexões, slots, memória e atenção do escalonador. Um proxy pode estabelecer um limite de concorrência específico para preservar o tráfego comum. Ao atingir o limite, a RFC recomenda 429 Too Many Requests, conforme a RFC 6585, com connection_limit_reached em Proxy-Status. Misturar esse evento com incremental_refused faria o cliente aplicar a mesma resposta a uma política permanente e a uma falta transitória de capacidade.

Microbuffer é escolha de desempenho, não licença para esperar para sempre

Liberar imediatamente cada escrita de um byte pode criar excesso de pacotes, ativações e trabalho. Também oferece a um atacante uma forma barata de impor custo. Por isso, a RFC permite uma pequena acumulação até um limiar de bytes ou de tempo.

O limite precisa ser finito. Lotes maiores podem melhorar eficiência e, ao mesmo tempo, piorar a latência percebida. Duas rotas que “suportam incremental” podem entregar resultados operacionais muito diferentes. A política de microbuffer deve ser tratada como parte da promessa do produto, não como detalhe invisível do proxy.

O primeiro byte, isoladamente, é uma métrica fraca. Um gateway pode liberar uma amostra rapidamente e depois reter o restante por dezenas de segundos. O cliente pode receber bytes que ainda não formam um evento válido. A mensagem pode terminar com status 200 depois de violar todas as metas interativas.

É necessário medir a conclusão dos cabeçalhos, o primeiro byte do conteúdo, a cadência seguinte, o maior intervalo sem bytes, o primeiro objeto que a aplicação consegue usar, a chegada dos trailers e o encerramento. A origem, cada fronteira intermediária e o consumidor enxergam tempos diferentes; nenhuma dessas observações substitui as outras.

Proxy-Status testemunha; não reproduz o que aconteceu

A RFC 9209 permite que intermediários descrevam o tratamento de uma resposta por Proxy-Status. Os membros seguem a ordem do proxy mais próximo da origem até o mais próximo do usuário. Um erro pode explicar por que um intermediário gerou a resposta; em alguns fluxos, informação tardia pode aparecer em um trailer.

O campo não é um registro forense completo. O intermediário escolhe quando expô-lo, pode omitir detalhes para proteger topologia e não é obrigado a incluir todo parâmetro. A própria RFC alerta que a informação não é verificada. Uma declaração de comportamento pode divergir do caminho de dados.

Assim, incremental_refused é uma evidência útil de uma decisão explícita. Sua ausência não prova suporte. Um hop que desconhece a RFC não emitirá o erro, uma política pode remover o campo e um trailer pode se perder. A prova nasce da reconciliação entre campo recebido, resultado do parser, regra aplicada, limiares de buffer, bytes recebidos e emitidos e observação a jusante.

Nem todo canal de duas vias deveria ser dois corpos progressivos

Com ?1 na requisição e na resposta, o mecanismo pode ajudar a criar um canal de bytes bidirecional e permitir resposta antes do término da requisição. A RFC também observa que Extended CONNECT para HTTP/2 e Extended CONNECT para HTTP/3 costumam se encaixar melhor na arquitetura do HTTP para protocolos realmente bidirecionais.

Uma representação consumida aos poucos, um feed de eventos e um protocolo duplex têm necessidades distintas de ciclo de vida, controle de fluxo e falha. Acomodar um protocolo duplex dentro de dois corpos pode facilitar um lançamento, mas depois cristalizar exceções em middleboxes, SDKs e integrações de clientes. O cabeçalho não escolhe essa arquitetura pela liderança.

Conhecimento prévio ou uma sonda pode demonstrar suporte de um recurso em uma rota específica. Não cria capacidade eterna. Software, regras de inspeção, balanceamento e carga mudam. A consulta de erratas da RFC 10036 não mostrava ocorrências em 30 de agosto de 2026; essa é uma observação datada, não uma garantia sobre o futuro.

A prova precisa unir intenção e entrega útil

Um registro defensável conserva recurso, direção, tentativa, versão HTTP, conexões, rota e retry; valor exato do campo em cada fronteira; resultado de parsing; versões de suporte e de política de segurança; admissão de capacidade; limiares de tempo e bytes; tempos de recepção e emissão; maior intervalo; primeiro evento útil; trailers, conclusão, cancelamento, reset, status e Proxy-Status.

Os testes precisam abranger escrita byte a byte, eventos lentos, rajadas, contrapressão, corpo que nunca termina, regra que exige inspeção completa, exaustão de concorrência, cancelamento, retry e mudança de rota. Uma demonstração rápida em um laboratório sem o conjunto real de intermediários só prova o laboratório.

A Primazia do Código em Execução de Heng Lu coloca a autoridade na sequência executada, não na publicação do padrão. Seu princípio de Especificação Inicial Mínima, Decisão Futura Localizada e Adoção Voluntária explica a contenção da RFC: um sinal comum coordena o necessário, enquanto segurança, capacidade e arquitetura permanecem locais. A distinção entre controle técnico e controle prático mostra por que o remetente pode expressar uma preferência válida sem possuir cada buffer.

A RFC 10036 permite fazer a pergunta certa ao caminho. A resposta só existe nos bytes que o caminho realmente liberou.