libproxy elige una ruta; su cliente realiza la conexión
Use los resultados de libproxy como candidatos de enrutamiento por URL en lugar de esperar que el descubrimiento redirija los sockets de la aplicación.
Si libproxy devuelve un URI de proxy mientras el siguiente socket se conecta directamente, revise la entrega. libproxy descubre la política; no intercepta todos los sockets que abre la aplicación.
- Consulte el recurso. En la API C documentada de libproxy 0.5, cree una fábrica de proxy y solicite la URL de destino real.
- Interprete los candidatos ordenados. Los resultados HTTP, SOCKS y directo requieren un tratamiento distinto. Mantenga su orden de preferencia y la política de fallo prevista.
- Configure el consumidor. Entregue el tipo de proxy elegido, el punto de conexión y la disposición de autenticación a un transporte que los admita. Un socket TCP en bruto no adquiere CONNECT ni negociación SOCKS a partir de un URI devuelto.
No guarde una sola respuesta como ruta para todos los destinos ni haga permanente el enrutamiento directo porque el primer proxy falló una vez.
Si el cliente HTTP ya integra el proxy del sistema o el descubrimiento PAC, elija un único propietario de la selección. Dos selectores independientes más otro envoltorio pueden producir una ruta que ninguna de las dos políticas pretendía.
En código nativo, siga el ciclo de vida de la fábrica y de la memoria de resultados de la API instalada. Reutilizar una fábrica puede conservar estado de descubrimiento útil, pero sigue necesitando una consulta para cada destino. Registre la selección por separado del resultado de la conexión: un URI devuelto no demuestra una autenticación, resolución o acceso posterior correctos.