A libproxy útvonalat választ; a kapcsolatot az ügyfeled hozza létre
A libproxy eredményeit URL-enkénti útvonaljelöltként használd, ahelyett hogy arra számítanál, hogy a felderítés átirányítja az alkalmazás socketjeit.
Ha a libproxy proxy URI-t ad vissza, miközben a következő socket közvetlenül csatlakozik, vizsgáld meg az átadást. A libproxy házirendet derít fel; nem fogja el az alkalmazás által megnyitott összes socketet.
- Kérdezd le az erőforrást. A dokumentált libproxy 0.5 C API-ban hozz létre proxy gyárat, és kérdezd le a tényleges cél URL-t.
- Értelmezd a rendezett jelölteket. A HTTP-, SOCKS- és közvetlen eredmények eltérő kezelést igényelnek. Tartsd meg a preferenciasorrendjüket és a szándékolt hibaüzleti szabályt.
- Konfiguráld a fogyasztót. Add át a kiválasztott proxy típust, végpontot és hitelesítési elrendezést egy olyan átvitelnek, amely támogatja őket. A nyers TCP socket nem szerez CONNECT vagy SOCKS egyeztetést egy visszaadott URI-ból.
Ne ments el egyetlen választ minden cél útvonalaként, és ne tedd véglegessé a közvetlen útvonalválasztást csak azért, mert az első proxy egyszer meghibásodott.
Ha a HTTP kliens már integrálja a rendszerproxy vagy a PAC felderítést, válassz egyetlen kiválasztási tulajdonost. Két független választó és még egy burkoló olyan útvonalat hozhat létre, amelyet egyik házirend sem szánt.
Natív kódban kövesd a telepített API gyár- és eredménymemória-életciklusát. A gyár újrafelhasználása megőrizhet hasznos felderítési állapotot, de továbbra is szükség van egy lekérdezésre minden célhoz. A kiválasztást a kapcsolat eredményétől külön naplózd: egy visszaadott URI nem bizonyít sikeres hitelesítést, névfeloldást vagy további hozzáférést.