Pumipili ang libproxy ng ruta; ang iyong client ang gumagawa ng koneksyon

Gamitin ang mga resulta ng libproxy bilang mga kandidatong ruta bawat URL sa halip na asahan na idi-redirect ng pagtuklas ang mga socket ng aplikasyon.

Kung nagbabalik ang libproxy ng proxy URI habang direktang kumokonekta ang susunod na socket, suriin ang paghahatid. Natutuklasan ng libproxy ang patakaran; hindi nito hinaharang ang bawat socket na binubuksan ng aplikasyon.

  1. Itanong ang resource. Sa dokumentadong libproxy 0.5 C API, gumawa ng proxy factory at hilingin ang aktwal na destination URL.
  2. Bigyang-kahulugan ang mga nakaayos na kandidato. Ang HTTP, SOCKS at direktang resulta ay nangangailangan ng magkaibang paghawak. Panatilihin ang kanilang pagkakasunod-sunod ng priyoridad at ang sinadyang patakaran sa pagkabigo.
  3. I-configure ang consumer. Ibigay ang napiling uri ng proxy, endpoint at kaayusan ng authentication sa isang transport na sumusuporta sa mga ito. Ang raw TCP socket ay hindi nakakakuha ng CONNECT o SOCKS na negosasyon mula sa ibinalik na URI.

Huwag iimbak ang isang sagot bilang ruta para sa lahat ng destinasyon at huwag gawing permanente ang direktang pagruruta dahil isang beses na nabigo ang unang proxy.

Kung isinasama na ng HTTP client ang system proxy o PAC discovery, pumili ng isang may-ari ng pagpili. Dalawang independiyenteng selector at isa pang wrapper ay makakagawa ng rutang hindi sinadya ng alinmang patakaran.

Sa native code, sundin ang lifecycle ng factory at result-memory ng naka-install na API. Ang muling paggamit ng factory ay maaaring magpanatili ng kapaki-pakinabang na estado ng pagtuklas, ngunit kailangan pa rin ng query para sa bawat destinasyon. I-log ang pagpili nang hiwalay sa resulta ng koneksyon: ang ibinalik na URI ay hindi nagpapatunay ng matagumpay na authentication, resolution o karagdagang pag-access.

Kaugnay na mga artikulo