libproxy бира руту; везу успоставља ваш клијент
Користите резултате libproxy као кандидате за рутирање по URL-у уместо да очекујете да ће откривање преусмери сокете апликације.
Ако libproxy врати прокси URI док се следећи сокет повезује директно, проверите предају. libproxy открива политику; не пресреће сваки сокет који апликација отвори.
- Питајте за ресурс. У документованом libproxy 0.5 C API-ју направите прокси фабрику и затражите стварни URL одредишта.
- Протумачите поређане кандидате. HTTP, SOCKS и директни резултати захтевају различито руковање. Задржите њихов редослед преференције и предвиђену политику неуспеха.
- Конфигуришите потрошача. Дајте изабрани тип проксија, крајњу тачку и распоред аутентификације транспорту који их подржава. Сирови TCP сокет не добија CONNECT ни SOCKS преговарање из враћеног URI-ја.
Не чувајте један одговор као руту за сва одредишта и не чините директно рутирање трајним зато што је први прокси једном заказао.
Ако HTTP клијент већ интегрише системски прокси или PAC откривање, изаберите једног власника селекције. Два независна селектора плус још један омотач могу произвести руту коју ниједна политика није намеравала.
У изворном коду пратите животни циклус фабрике и меморије резултата инсталираног API-ја. Поновна употреба фабрике може задржати корисно стање откривања, али још увек захтева упит за свако одредиште. Бележите селекцију одвојено од исхода везе: враћени URI не доказује успешну аутентификацију, разрешавање или даљи приступ.