Resumo

  • Em 1997, 305 Use Proxy dizia ao cliente para repetir a solicitação pelo proxy indicado em Location.
  • O RFC de 1999 limitou o comando a uma solicitação e a respostas do servidor de origem; o texto de 2014 o desaconselhou por riscos da configuração de proxy dentro da conversa HTTP.

Você pede um livro à livraria e ela responde com o endereço de um intermediário: “Converse com ele primeiro.” A loja continua no mesmo lugar. O trajeto da sua mensagem ganhou um balcão que você não escolheu. Essa foi a proposta do 305 Use Proxy, um antigo código de resposta HTTP que tentava apontar o proxy por onde o cliente deveria refazer sua solicitação.

O RFC 2068, de janeiro de 1997, formulou a regra de modo direto. O recurso solicitado teria de ser acessado pelo proxy fornecido no campo Location, e o destinatário deveria repetir o pedido por ali. O próprio RFC define um proxy como agente que recebe solicitações e as encaminha, podendo reformatar parte da mensagem. Colocar um agente desse tipo na estrada é uma escolha sobre quem toca no tráfego.

O código foi classificado entre os redirecionamentos, mas não fazia a mesma coisa que mudar o endereço de um recurso. 301 aponta outro URI para o destino. 305 pretendia manter o destino e trocar a rota. O cliente pode ter configuração própria de proxy, limites de rede e critérios de confiança. A resposta vinda do servidor queria interferir nessa escolha. Faltava dizer até onde tal ordem alcançava.

O RFC 2616, publicado em junho de 1999, acrescentou duas travas: a instrução valia para uma única solicitação, e somente o servidor de origem podia emitir 305. Uma nota admite que o RFC anterior não tinha sido claro nesses pontos e que desrespeitar as restrições trazia consequências importantes para a segurança. Uma resposta isolada deixava de parecer autorização para alterar todos os trajetos futuros. Um intermediário também perdia a possibilidade de nomear outro intermediário em nome da origem.

O mecanismo ainda colocava a escolha do proxy dentro da própria troca HTTP que ele tentava desviar. O RFC 7231, de 2014, marcou 305 como desaconselhado. Seu resumo de alterações aponta explicitamente preocupações de segurança com a configuração de proxy dentro do canal. O ponto sensível era o volante: a resposta HTTP escolhia o proxy que receberia a próxima solicitação do cliente.

No RFC 9110, de 2022, 305 ainda ocupa uma linha da lista de códigos, acompanhado do aviso de que está desaconselhado. Os números antigos sobrevivem como placas guardadas num depósito: ajudam a entender mapas passados, enquanto a orientação para o tráfego atual mudou.

Antes de a solicitação chegar ao servidor, um proxy pode recebê-la. 305 entregava ao servidor uma maneira de escolher essa parada intermediária pela resposta. A norma pôs grades em volta da ideia em 1999 e encerrou seu uso recomendado em 2014. O caminho até um recurso também é uma decisão de autoridade.