Resumo

  • 340 apenas abria o envio; o resultado real, 240 ou 441, vinha depois do artigo completo.
  • A perda da conexão podia esconder uma resposta positiva sem desfazer a decisão já tomada pelo servidor.
  • Reusar o Message-ID vinculava a nova tentativa ao mesmo artigo, sem prometer publicação imediata ou processamento exatamente uma vez.

O cliente terminou de falar e ainda assim não sabia o resultado

Há uma falha especialmente difícil quando todo o conteúdo já atravessou a rede. O cliente enviou cabeçalhos, texto e terminador. Se o caminho de volta quebra, ele não distingue uma rejeição de uma aceitação cujo aviso se perdeu.

Repetir com outro identificador pode criar duas publicações. Não repetir pode abandonar uma tentativa que realmente falhou. A saída precisava conservar a intenção sem fingir que o passado era conhecido.

POST separava licença para enviar de aceitação

O RFC 977 definiu duas decisões. 340 mandava o cliente apresentar o artigo; 440 recusava a postagem. Só depois do conteúdo completo o servidor respondia 240 article posted ok ou 441 posting failed.

O RFC 3977 manteve a divisão, proibiu pipeline para POST e localizou a resposta final depois da sequência terminadora. Portanto, o primeiro sim não transferia custódia. Ele apenas aceitava começar a entrada.

Um 240 deveria indicar que, salvo erro imprevisto, o artigo seria disponibilizado localmente ou transferido conforme a função do servidor, talvez após processamento adicional. Um conteúdo indesejado deveria receber 441, em vez de ser aceito e descartado sem aviso.

A superfície de leitura vinha depois

Mesmo com 240, o cliente não podia supor que outros leitores já encontrariam o artigo; a norma recomenda uma verificação explícita, como STAT. Sem resposta positiva, por outro lado, também não podia presumir sucesso.

O RFC 5537 organiza as responsabilidades: o agente de postagem prepara um protoartigo; o agente de injeção o valida; um moderador pode recebê-lo; agentes de retransmissão o propagam; o agente servidor o mostra aos leitores. Uma instalação pode reunir funções, mas a evidência de uma etapa não prova as demais.

Por isso, uma busca vazia logo após a queda não é confirmação de falha. O artigo pode estar numa fila de moderação ou ainda não ter alcançado aquela visão de leitura.

A nova sessão precisava perguntar pelo mesmo artigo

RFC 3977 diz que, se a sessão for interrompida antes da resposta, um resultado afirmativo pode ter sido enviado e perdido. Na sessão seguinte, o cliente deveria verificar o sucesso antes de reenviar ou garantir que a nova tentativa recebesse o mesmo Message-ID.

A segunda alternativa é preferida porque o artigo talvez ainda não esteja legível, especialmente durante moderação. O apêndice recomenda colocar um campo Message-ID idêntico em cada POST e pede que o servidor reconheça os envios como o mesmo artigo.

Esse identificador não é recibo da primeira transação. Não autentica autoria e não assina o corpo. Ele impede que a tentativa de recuperação declare uma nova entidade. Um ID novo, ainda que acompanhe texto idêntico, pode iniciar outra moderação, outra propagação e outra retenção.

O histórico tornava a repetição comparável

O RFC 5536 define Message-ID como identificador único e ressalta a necessidade de comparação rápida em Netnews. Como a propagação em inundação oferece o mesmo artigo por vários pares, o RFC 5537 exige histórico dos identificadores vistos para rejeitar duplicatas.

A repetição com o mesmo ID pode então ser alinhada ao artigo já conhecido. Isso não cria uma garantia exactly-once: históricos expiram, políticas locais divergem e falhas podem ocorrer em torno da persistência. A contribuição é mais sóbria. Em vez de dois artigos parecidos, há duas tentativas relacionadas a uma única identidade e uma trilha que separa recebimento, resposta, injeção, moderação, retransmissão e leitura.

O registro de parâmetros NNTP da IANA registra POST com referência ao RFC 3977. O registro não comprova permissão num servidor, duração de histórico ou disponibilidade atual.

O NNTP não eliminou a janela em que a execução pode ter ocorrido e o aviso sumido. Ele preservou o nome do trabalho dentro dessa janela. Assim, recuperar uma resposta incerta não precisava criar uma segunda história editorial.

Sources