libproxy wybiera trasę; połączenie nawiązuje twój klient
Używaj wyników libproxy jako kandydatów do trasowania dla poszczególnych adresów URL, zamiast oczekiwać, że wykrywanie przekieruje gniazda aplikacji.
Jeśli libproxy zwraca URI proxy, a kolejne gniazdo łączy się bezpośrednio, sprawdź przekazanie. libproxy wykrywa politykę; nie przechwytuje każdego gniazda otwieranego przez aplikację.
- Zapytaj o zasób. W udokumentowanym interfejsie libproxy 0.5 C API utwórz fabrykę proxy i poproś o rzeczywisty docelowy adres URL.
- Zinterpretuj uporządkowanych kandydatów. Wyniki HTTP, SOCKS i bezpośrednie wymagają innej obsługi. Zachowaj ich kolejność preferencji i zamierzoną politykę błędów.
- Skonfiguruj konsumenta. Przekaż wybrany typ proxy, punkt końcowy i sposób uwierzytelniania transportowi, który je obsługuje. Surowe gniazdo TCP nie uzyskuje negocjacji CONNECT ani SOCKS ze zwróconego URI.
Nie zapisuj jednej odpowiedzi jako trasy dla wszystkich miejsc docelowych i nie czyń trasowania bezpośredniego trwałym tylko dlatego, że pierwsze proxy raz zawiodło.
Jeśli klient HTTP już integruje proxy systemowe lub wykrywanie PAC, wybierz jednego właściciela wyboru. Dwa niezależne selektory i jeszcze jedna otoczka mogą dać trasę, której nie zamierzała żadna z polityk.
W kodzie natywnym przestrzegaj cyklu życia fabryki i pamięci wyników zainstalowanego interfejsu. Ponowne użycie fabryki może zachować przydatny stan wykrywania, ale nadal wymaga zapytania dla każdego celu. Rejestruj wybór oddzielnie od wyniku połączenia: zwrócony URI nie dowodzi udanego uwierzytelnienia, rozwiązywania ani dalszego dostępu.