libproxy kiest in rûte; jo klant makket de ferbining
Brûk libproxy-resultaten as rûtekandidaten per URL ynstee fan te ferwachtsjen dat de ûntdekking de sockets fan de applikaasje trochstjoert.
As libproxy in proxy-URI weromjout wylst de folgjende socket direkt ferbynt, kontrolearje de oerdracht. libproxy ûntdekt belied; it ûnderskept net elke socket dy't de applikaasje iepenet.
- Freegje om de boarne. Meitsje yn 'e dokumintearre libproxy 0.5 C-API in proxyfabryk en freegje om de eigentlike bestimming-URL.
- Ynterpretearje de oardere kandidaten. HTTP-, SOCKS- en direkte resultaten fereaskje oare behanneling. Behâld har foarkarsfolchoarder en it bedoelde flaterbelied.
- Konfigurearje de konsumint. Jou it keazen proxytype, einpunt en de autentikaasjeregeling oan in transport dat se stipet. In rau TCP-socket krijt gjin CONNECT- of SOCKS-ûnderhanneling fan in weromjûn URI.
Bewarje net ien antwurd as de rûte foar alle bestimmingen en meitsje direkte routing net permanint om't de earste proxy ien kear mislearre.
As de HTTP-klant al systeemproxy of PAC-ûntdekking yntegrearret, kies dan ien eigner fan 'e seleksje. Twa ûnôfhinklike selektearders plus noch in wrapper kinne in rûte produsearje dy't gjin fan beide beliedbedoelingen hie.
Folgje yn native koade de libbenssyklus fan fabryk en resultaatgeheugen fan 'e ynstallearre API. Herbrûken fan in fabryk kin nuttige ûntdekkingssteat behâlde, mar it hat noch hieltyd in fraach nedich foar elke bestimming. Log de seleksje apart fan it ferbiningsresultaat: in weromjûn URI bewisset gjin slagge autentikaasje, resolúsje of fierdere tagong.