libproxy выбірае маршрут; ваш кліент усталёўвае злучэнне
Выкарыстоўвайце вынікі libproxy як кандыдатаў на маршрут для кожнага URL, а не спадзявайцеся, што выяўленне перанакіруе сокеты праграмы.
Калі libproxy вяртае проксі-URI, а наступны сокет злучаецца наўпрост, праверце перадачу. libproxy выяўляе палітыку; ён не перахоплівае кожны сокет, які адкрывае праграма.
- Запытайце рэсурс. У дакументаваным libproxy 0.5 C API стварыце фабрыку проксі і запытайце фактычны URL прызначэння.
- Інтэрпрэтуйце ўпарадкаваныя кандыдаты. Вынікі HTTP, SOCKS і прамыя патрабуюць рознай апрацоўкі. Захоўвайце іх парадак перавагі і прадугледжаную палітыку збояў.
- Наладзьце спажыўца. Перадайце абраны тып проксі, канчатковы пункт і схему аўтэнтыфікацыі транспарту, які іх падтрымлівае. Сыры TCP-сокет не атрымлівае CONNECT або SOCKS-перамовы з вернутага URI.
Не захоўвайце адзін адказ як маршрут для ўсіх прызначэнняў і не рабіце прамое маршрутызаванне пастаянным з-за аднаго збою першага проксі.
Калі HTTP-кліент ужо інтэгруе сістэмны проксі або выяўленне PAC, выберыце аднаго ўладальніка выбару. Два незалежныя сялектары плюс яшчэ адна абгортка могуць стварыць маршрут, якога не прадугледжвала ні адна палітыка.
У родным кодзе прытрымлівайцеся жыццёвага цыкла фабрыкі і памяці вынікаў усталяванага API. Паўторнае выкарыстанне фабрыкі можа захаваць карысны стан выяўлення, але яно ўсё яшчэ патрабуе запыту для кожнага прызначэння. Запісвайце выбар асобна ад выніку злучэння: вернуты URI не пацвярджае паспяховую аўтэнтыфікацыю, разбор або далейшы доступ.