Novas tentativas de autenticação pelo proxy e corpos de envio não repetíveis
Entenda por que novas tentativas de autenticação podem expor um fluxo de envio de uso único, e escolha deliberadamente buffer limitado ou conteúdo repetível.
Um GET pode autenticar-se através de um proxy enquanto um POST ou PUT falha com um erro de corpo não repetível ou de rebobinamento. A conta pode estar correta: uma troca de autenticação pode exigir outra requisição depois que o cliente já consumiu o envio.
| Origem do corpo | Escolha de repetição |
|---|---|
| Corpo pequeno e finito | Um buffer limitado pode reter os seus bytes. |
| Arquivo pesquisável | A interface de rebobinamento suportada pelo cliente pode torná-lo repetível. |
| Gerador, pipe ou produtor ao vivo | Uma origem de uso único pode exigir outro design. |
libcurl documenta callbacks de busca para usos incluindo autenticação em múltiplas passagens. Jersey oferece modos de processamento de entidades com buffer e fragmentados, sujeitos ao comportamento do conector. Um exemplo de conector Jersey 2 Apache mostra a configuração com buffer. Nenhum dos dois torna apropriados os envios ilimitados em memória.
Reproduza o método e a origem do corpo que falham. Um GET preparatório não tem envio para repetir e não prova que um envio posterior compartilhe a sua conexão ou estado de autenticação. Um novo destino, objeto de cliente ou política de conexão podem mudar isso. Um corpo baseado em arquivo e um fluxo ao vivo também diferem mesmo quando o texto de exemplo é o mesmo.
Se você usar buffer, defina o limite de tamanho, o local de armazenamento e o tempo de vida. Envios simultâneos multiplicam o custo, e dados sensíveis permanecem onde o buffer for mantido.
Pré-autenticação para um proxy compatível conhecido pode evitar um desafio inicial. Não pode excluir cada rodada de autenticação, redirecionamento ou conexão fechada posterior que possa exigir outra tentativa.
Mantenha juntos a resposta do proxy, o ponto de consumo do corpo e o erro de repetição. Depois distinga a repetição de protocolo de um resultado de aplicação incerto: um envio pode ter sido processado antes de a sua resposta se perder. Siga as regras de idempotência do destino antes de enviá-lo novamente.