Пренасочување на избрани HTTP барања од Squid кон HTTPS

Squid може да побара од прелистувачот повторно да проба избран HTTP URL преку HTTPS. Дестинацијата веќе мора да го служи соодветниот ресурс преку HTTPS; извршувањето на Squid на Raspberry Pi не ја создава таа можност на веб-локацијата.

За интерфејсот url_rewrite_program на Squid 7, helper може да врати клиентско пренасочување како ова:

OK status=307 url="https://www.example.com/help"

Ова е еден илустративен helper одговор за соодветно барање, не целосна helper програма. Прелистувачот го добива пренасочувањето и прави ново барање до HTTPS URL. URL надвор од политиката за надградба може да добие OK и да остане непроменет.

Користете познат список на дестинации со HTTPS поддршка и анализирајте го дојдовниот URL. Зачувајте ја предвидената патека и query, земете ги предвид експлицитните порти и свесно ракувајте со методите на барање. Слепо заменување на секој http префикс претпоставува дека секој извор има еквивалентна HTTPS услуга.

Helper мора да одговори на секој влезен ред според протоколот на инсталираната верзија на Squid. Ако се овозможени паралелни helper канали, зачувајте го идентификаторот на каналот во одговорот. Стариот гол пример 301:URL не е заменлив со тековниот формат result-and-key/value.

Изберете клиентско пренасочување кога прелистувачот треба да го знае новиот URL. Одговорот rewrite-url наместо тоа бара Squid да преземе друг URL зад првобитното барање на клиентот, што може да ги остави URL-ата на апликацијата и состојбата неконзистентни.

Првобитното HTTP барање веќе стигнало до Squid пред helper да може да го пренасочи. Оваа политика не може ретроактивно да го заштити тоа барање. TLS започнува на следната HTTPS врска; само CONNECT тунел не обезбедува никакво шифрирање.