libproxy kies 'n roete; jou kliënt maak die verbinding
Gebruik libproxy-resultate as roeteringskandidate per URL eerder as om te verwag dat ontdekking die toepassing se sockets herlei.
As libproxy 'n proxy-URI terugstuur terwyl die volgende socket direk verbind, ondersoek die oorhandiging. libproxy ontdek beleid; dit onderskep nie elke socket wat die toepassing oopmaak nie.
- Vra vir die hulpbron. Skep in die gedokumenteerde libproxy 0.5 C-API 'n proxy-fabriek en vra vir die werklike bestemming-URL.
- Interpreteer die geordende kandidate. HTTP-, SOCKS- en direkte resultate vereis verskillende hantering. Behou hul voorkeurorde en die beoogde foutbeleid.
- Konfigureer die verbruiker. Gee die gekose proxy-tipe, eindpunt en stawingsreëling aan 'n transport wat dit ondersteun. 'n Rou TCP-socket verkry nie CONNECT- of SOCKS-onderhandeling uit 'n teruggekeerde URI nie.
Moenie een antwoord as die roete vir elke bestemming stoor nie, en maak nie direkte roetering permanent omdat die eerste proxy een keer misluk het nie.
As die HTTP-kliënt reeds stelselproxy- of PAC-ontdekking integreer, kies een eienaar vir die seleksie. Twee onafhanklike kiesers plus nog 'n omhulsel kan 'n roete lewer wat geen van die twee beleide bedoel het nie.
Volg in inheemse kode die geïnstalleerde API se fabriek- en resultaatgeheue-lewensiklus. Hergebruik van 'n fabriek kan nuttige ontdekkingstoestand behou, maar dit benodig steeds 'n navraag vir elke bestemming. Teken seleksie afsonderlik van die verbindingsuitkoms aan: 'n teruggekeerde URI bewys nie suksesvolle stawing, naamresolusie of verdere toegang nie.