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