O libproxy escolhe uma rota; o seu cliente faz a conexão
Use os resultados do libproxy como candidatos de encaminhamento por URL em vez de esperar que a descoberta redirecione os sockets da aplicação.
Se o libproxy devolve um URI de proxy enquanto o socket seguinte se liga diretamente, verifique a entrega. O libproxy descobre a política; não interceta todos os sockets que a aplicação abre.
- Consulte o recurso. Na API C documentada do libproxy 0.5, crie uma fábrica de proxy e peça o URL de destino real.
- Interprete os candidatos ordenados. Os resultados HTTP, SOCKS e direto exigem tratamento diferente. Mantenha a ordem de preferência e a política de falha pretendida.
- Configure o consumidor. Entregue o tipo de proxy escolhido, o endpoint e a disposição de autenticação a um transporte que os suporte. Um socket TCP cru não obtém negociação CONNECT nem SOCKS a partir de um URI devolvido.
Não guarde uma única resposta como rota para todos os destinos nem torne o encaminhamento direto permanente só porque o primeiro proxy falhou uma vez.
Se o cliente HTTP já integra o proxy do sistema ou a descoberta PAC, escolha um único dono da seleção. Dois seletores independentes mais outro invólucro podem produzir uma rota que nenhuma das políticas pretendia.
Em código nativo, siga o ciclo de vida da fábrica e da memória de resultados da API instalada. Reutilizar uma fábrica pode conservar estado de descoberta útil, mas continua a exigir uma consulta para cada destino. Registe a seleção separadamente do resultado da ligação: um URI devolvido não prova autenticação, resolução ou acesso posterior bem-sucedidos.