libproxy zgjedh një rrugë; klienti juaj bën lidhjen
Përdorni rezultatet e libproxy si kandidatë rrugëtimi për çdo URL në vend që të prisni që zbulimi të ridrejtojë soketat e aplikacionit.
Nëse libproxy kthen një URI proxy ndërsa soketi tjetër lidhet drejtpërdrejt, kontrolloni dorëzimin. libproxy zbulon politikën; nuk i kap të gjitha soketat që hap aplikacioni.
- Pyet për burimin. Në API-n C të dokumentuar libproxy 0.5, krijoni një fabrikë proxy dhe kërkoni URL-në reale të destinacionit.
- Interpreto kandidatët e renditur. Rezultatet HTTP, SOCKS dhe ato të drejtpërdrejta kërkojnë trajtim të ndryshëm. Ruani rendin e preferencës dhe politikën e synuar të dështimit.
- Konfiguro konsumatorin. Jepni llojin e zgjedhur të proxy-t, pikën fundore dhe rregullimin e autentikimit një transporti që i mbështet ato. Një soket TCP i papërpunuar nuk fiton negociim CONNECT ose SOCKS nga një URI e kthyer.
Mos ruani një përgjigje të vetme si rrugën për të gjitha destinacionet dhe mos e bëni të përhershëm rrugëtimin e drejtpërdrejtë vetëm sepse proxy-ja e parë dështoi një herë.
Nëse klienti HTTP tashmë integron proxy-n e sistemit ose zbulimin PAC, zgjidhni një pronar të vetëm të zgjedhjes. Dy përzgjedhës të pavarur plus një mbështjellës tjetër mund të prodhojnë një rrugë që asnjëra politikë nuk e synonte.
Në kod nativ, ndiq ciklin e jetës së fabrikës dhe kujtesës së rezultateve të API-së të instaluar. Ripërdorimi i një fabrike mund të ruajë gjendje të dobishme zbulimi, por ende kërkon një pyetje për çdo destinacion. Regjistro zgjedhjen ndaras nga rezultati i lidhjes: një URI e kthyer nuk provon autentikim, zgjidhje ose akses të mëtejshëm të suksesshëm.