libproxy velger en rute; klienten din oppretter forbindelsen
Bruk libproxy-resultater som rutevalgskandidater per URL i stedet for å forvente at oppdagelsen omdirigerer applikasjonens sockets.
Hvis libproxy returnerer en proxy-URI mens neste socket kobler til direkte, undersøk overleveringen. libproxy oppdager policy; det fanger ikke opp hver socket applikasjonen åpner.
- Spør etter ressursen. I det dokumenterte libproxy 0.5 C-API-et oppretter du en proxyfabrikk og ber om den faktiske mål-URL-en.
- Tolk de ordnede kandidatene. HTTP-, SOCKS- og direkte resultater krever ulik håndtering. Behold preferanserekkefølgen og den tiltenkte feilpolicyen.
- Konfigurer forbrukeren. Gi den valgte proxytypen, endepunktet og autentiseringsoppsettet til en transport som støtter dem. En rå TCP-socket får ikke CONNECT- eller SOCKS-forhandling fra en returnert URI.
Ikke lagre ett svar som ruten for alle mål, og ikke gjør direkte ruting permanent fordi den første proxyen feilet én gang.
Hvis HTTP-klienten allerede integrerer systemproxy eller PAC-oppdagelse, velg én eier av valget. To uavhengige velgere pluss en ekstra innpakning kan gi en rute ingen av de to policyene hadde til hensikt.
I innebygd kode, følg livssyklusen til fabrikken og resultatminnet i det installerte API-et. Gjenbruk av en fabrikk kan beholde nyttig oppdagelsestilstand, men den trenger fortsatt en forespørsel for hvert mål. Logg valget atskilt fra forbindelsesresultatet: en returnert URI beviser ikke vellykket autentisering, oppslag eller videre tilgang.