libproxy elektas itineron; via kliento faras la konekton
Uzu rezultojn de libproxy kiel itinerajn kandidatojn por ĉiu URL anstataŭ atendi, ke la malkovro alidirektu la ingojn de la aplikaĵo.
Se libproxy redonas prokurilan URI dum la sekva ingo konektas rekte, kontrolu la transdonon. libproxy malkovras politikon; ĝi ne interkaptas ĉiun ingon, kiun la aplikaĵo malfermas.
- Demandu la rimedon. En la dokumentita C-API de libproxy 0.5, kreu prokurilan fabrikon kaj demandu la realan celan URL-on.
- Interpretu la ordigitajn kandidatojn. Rezultoj HTTP, SOCKS kaj rektaj bezonas malsamajn traktadojn. Konservu ilian preferan ordon kaj la celatan malsukcesan politikon.
- Agordu la konsumanton. Donu la elektitan prokurilan tipon, finpunkton kaj aŭtentikigan aranĝon al transporto, kiu subtenas ilin. Kruda TCP-ingo ne akiras CONNECT nek SOCKS-intertraktadon el redonita URI.
Ne konservu unu respondon kiel la itineron por ĉiuj celoj kaj ne faru rektan itineradon permanenta nur ĉar la unua prokurilo malsukcesis unufoje.
Se la HTTP-kliento jam integras sistemprokurilon aŭ PAC-malkovron, elektu unu posedanton de la elekto. Du sendependaj selektiloj plus ankoraŭ unu ĉirkaŭilo povas produkti itineron, kiun neniu el la du politikoj celis.
En denaska kodo, sekvu la vivciklon de fabriko kaj rezulta memoro de la instalita API. Reuzi fabrikon povas konservi utilan malkovran staton, sed ĝi ankoraŭ bezonas demandon por ĉiu celo. Registru elekton aparte de la konekta rezulto: redonita URI ne pruvas sukcesan aŭtentikigon, solvon aŭ pluan aliron.