Qt HttpProxy супраць HttpCachingProxy: магчымасці CONNECT
Адрознівайце HttpProxy у Qt з падтрымкай CONNECT ад тыпу HttpCachingProxy, прызначанага толькі для запытаў.
Qt адрознівае HTTP-проксі, здольны тунэляваць, ад свайго тыпу HTTP-проксі толькі для кэшавання. Абодва назвы змяшчаюць HTTP, але іх магчымасці злучэння розныя.
| Тып Qt | Роля злучэння |
|---|---|
| HttpProxy | Падтрымка HTTP CONNECT для знешніх TCP-злучэнняў |
| HttpCachingProxy | Звычайныя HTTP-запыты ў сумяшчальным кліенце на аснове запытаў |
| Socks5Proxy | Перамовы SOCKS5 з яго дакументаванымі транспартнымі магчымасцямі |
QNetworkAccessManager, які робіць звычайны HTTP-запыт, можа выкарыстоўваць тып, арыентаваны на запыты. QTcpSocket, якому патрэбен байтавы тунэль, патрабуе проксі з TunnelingCapability. Qt асабліва папярэджвае супраць усталявання прадвызначанага проксі праграмы без гэтай магчымасці, калі агульныя TCP-сокеты павінны яго выкарыстоўваць.
Выберыце тып пратакола перад прызначэннем канчатковай кропкі. Для дазволенага публічнага HTTP-запыту без аўтэнтыфікацыі проксі спіс HTTP-проксі прапануе адрасы; тып Qt усё яшчэ павінен забяспечваць магчымасць, неабходную гэтаму запыту. Калі даць HttpCachingProxy порт, які выкарыстоўвае служба CONNECT, гэта не дадае адсутную магчымасць у гэты выбар Qt.
Метка толькі для кэшавання таксама не абяцае, што кожны адказ будзе захаваны або паўторна выкарыстаны аддаленым серверам. Яна апісвае падтрымліваны кліенцкім інтэрфейсам стыль выкарыстання проксі, а палітыка адказаў HTTP па-ранейшаму кіруе паўторным выкарыстаннем кэша.