libproxy valib marsruudi; ühenduse loob teie klient
Kasutage libproxy tulemusi URL-põhiste marsruudikandidaatidena, selle asemel et oodata, et avastamine rakenduse soklid ümber suunab.
Kui libproxy tagastab puhverserveri URI, kuid järgmine sokkel ühendub otse, kontrollige üleandmist. libproxy avastab poliitika; see ei püüa kinni iga soklit, mille rakendus avab.
- Päri ressurssi. Dokumenteeritud libproxy 0.5 C API-s looge puhverserveri tehas ja küsige tegelikku siht-URL-i.
- Tõlgenda järjestatud kandidaate. HTTP, SOCKS ja otsesed tulemused nõuavad erinevat käsitlemist. Säilitage nende eelistusjärjekord ja kavandatud tõrkepoliitika.
- Seadista tarbija. Andke valitud puhverserveri tüüp, lõpp-punkt ja autentimiskorraldus transporti, mis neid toetab. Toores TCP-sokkel ei saa tagastatud URI-st CONNECT ega SOCKS-läbirääkimisi.
Ärge salvestage üht vastust kõigi sihtkohtade marsruudiks ega tehke otsest marsruutimist püsivaks sellepärast, et esimene puhverserver korra ebaõnnestus.
Kui HTTP-klient juba integreerib süsteemse puhverserveri või PAC-avastuse, valige üks valiku omanik. Kaks sõltumatut valijat ja veel üks mähis võivad tekitada marsruudi, mida kumbki poliitika ei kavandanud.
Natiivses koodis järgige paigaldatud API tehase ja tulemuste mälu elutsüklit. Tehase korduskasutus võib säilitada kasulikku avastusolekut, kuid vajab endiselt päringut iga sihtkoha jaoks. Logige valikut ühenduse tulemusest eraldi: tagastatud URI ei tõesta edukat autentimist, lahendust ega edasist juurdepääsu.