libproxy kiest een route; uw client maakt de verbinding
Gebruik libproxy-resultaten als routeringskandidaten per URL in plaats van te verwachten dat de detectie de sockets van de toepassing omleidt.
Als libproxy een proxy-URI retourneert terwijl de volgende socket rechtstreeks verbindt, controleer de overdracht. libproxy ontdekt beleid; het onderschept niet elke socket die de toepassing opent.
- Vraag de resource op. Maak in de gedocumenteerde libproxy 0.5 C-API een proxyfabriek en vraag de werkelijke bestemmings-URL op.
- Interpreteer de geordende kandidaten. HTTP-, SOCKS- en directe resultaten vereisen een andere behandeling. Behoud hun voorkeursvolgorde en het bedoelde foutbeleid.
- Configureer de consument. Geef het gekozen proxytype, het eindpunt en de authenticatieregeling door aan een transport dat deze ondersteunt. Een ruwe TCP-socket krijgt geen CONNECT- of SOCKS-onderhandeling uit een geretourneerde URI.
Bewaar niet één antwoord als de route voor alle bestemmingen en maak directe routering niet permanent omdat de eerste proxy één keer faalde.
Als de HTTP-client al systeemproxy of PAC-detectie integreert, kies dan één eigenaar van de selectie. Twee onafhankelijke selectors plus nog een wrapper kunnen een route opleveren die geen van beide beleidsregels bedoelde.
Volg in native code de levenscyclus van de fabriek en het resultaatgeheugen van de geïnstalleerde API. Hergebruik van een fabriek kan nuttige detectiestatus behouden, maar vereist nog steeds een query per bestemming. Log de selectie apart van het verbindingsresultaat: een geretourneerde URI bewijst geen geslaagde authenticatie, resolutie of verdere toegang.