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