libproxy valitsee reitin; asiakkaasi muodostaa yhteyden
Käytä libproxy-tuloksia URL-kohtaisina reittiehdokkaina sen sijaan, että odottaisit havaitsemisen ohjaavan sovelluksen soketit uudelleen.
Jos libproxy palauttaa välityspalvelimen URI:n, mutta seuraava soketti yhdistää suoraan, tarkista luovutus. libproxy havaitsee käytännön; se ei sieppaa jokaista sokettia, jonka sovellus avaa.
- Kysy resurssia. Dokumentoidussa libproxy 0.5 C -rajapinnassa luo välityspalvelintehdas ja kysy todellinen kohde-URL.
- Tulkitse järjestetyt ehdokkaat. HTTP-, SOCKS- ja suorat tulokset vaativat erilaista käsittelyä. Säilytä niiden etusijajärjestys ja aiottu virhekäytäntö.
- Määritä kuluttaja. Anna valittu välityspalvelintyyppi, päätepiste ja todennusjärjestely kuljetukselle, joka tukee niitä. Raaka TCP-soketti ei saa CONNECT- tai SOCKS-neuvottelua palautetusta URI:sta.
Älä tallenna yhtä vastausta reitiksi kaikille kohteille äläkä tee suorasta reitityksestä pysyvää siksi, että ensimmäinen välityspalvelin epäonnistui kerran.
Jos HTTP-asiakas integroi jo järjestelmän välityspalvelimen tai PAC-havaitsemisen, valitse yksi valinnan omistaja. Kaksi riippumatonta valitsinta ja vielä yksi kääre voivat tuottaa reitin, jota kumpikaan käytäntö ei tarkoittanut.
Natiivikoodissa noudata asennetun rajapinnan tehtaan ja tulosmuistin elinkaarta. Tehtaan uudelleenkäyttö voi säilyttää hyödyllisen havaintotilan, mutta se tarvitsee silti kyselyn jokaista kohdetta varten. Kirjaa valinta erikseen yhteyden tuloksesta: palautettu URI ei todista onnistunutta todennusta, nimenratkaisua tai jatkopääsyä.