Перанакіраванне выбраных HTTP-запытаў з Squid на HTTPS
Вяртайце client redirect для вядомых сайтаў з падтрымкай HTTPS замест таго, каб моўчкі змяняць кожны HTTP origin URL або меркаваць, што проксі можа стварыць падтрымку origin TLS.
Squid можа папрасіць браўзер паўтарыць выбраны HTTP URL праз HTTPS. Прызначэнне ўжо павінна аддаваць адпаведны рэсурс праз HTTPS; запуск Squid на Raspberry Pi не стварае гэтай магчымасці на сайце.
Для інтэрфейсу url_rewrite_program у Squid 7 helper можа вярнуць client redirect, напрыклад:
OK status=307 url="https://www.example.com/help"Гэта адзін паказальны адказ helper для адпаведнага запыту, а не поўная праграма helper. Браўзер атрымлівае перанакіраванне і робіць новы запыт да HTTPS URL. URL па-за палітыкай абнаўлення можа атрымаць OK і застацца нязменным.
Выкарыстоўвайце вядомы спіс прызначэнняў з падтрымкай HTTPS і разбірайце ўваходны URL. Захоўвайце меркаваны шлях і query, улічвайце явныя парты і свядома апрацоўвайце метады запыту. Сляпое замяшчэнне кожнага прэфікса http мяркуе, што кожны origin мае эквівалентную службу HTTPS.
Helper павінен адказваць на кожны радок уводу па пратаколе ўсталяванай версіі Squid. Калі ўключаны паралельныя каналы helper, захоўвайце ідэнтыфікатар канала ў адказе. Стары голы прыклад 301:URL не ўзаемазаменны з бягучым фарматам result-and-key/value.
Выбірайце client redirect, калі браўзер павінен ведаць новы URL. Адказ rewrite-url заміж гэтага просіць Squid атрымаць іншы URL за першапачатковым запытам кліента, што можа пакінуць URL праграмы і стан несугучнымі.
Першапачатковы HTTP-запыт ужо дайшоў да Squid, перш чым helper зможа яго перанакіраваць. Гэтая палітыка не можа заднім числом абараніць той запыт. TLS пачынаецца ў наступным HTTPS-злучэнні; толькі CONNECT-тунэль не дае шыфравання.