Пренасочване на избрани HTTP заявки от Squid към HTTPS
Върнете клиентско пренасочване за известни сайтове с HTTPS поддръжка, вместо тихо да променяте всеки HTTP origin URL или да приемате, че проксито може да създаде origin TLS поддръжка.
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 префикс предполага, че всеки origin има еквивалентна HTTPS услуга.
Helper трябва да отговаря на всеки входен ред по протокола на инсталираната версия на Squid. Ако са включени паралелни helper канали, запазете идентификатора на канала в отговора. Старият гол пример 301:URL не е взаимозаменяем с текущия формат result-and-key/value.
Изберете клиентско пренасочване, когато браузърът трябва да знае новия URL. Отговор rewrite-url вместо това кара Squid да извлече друг URL зад първоначалната заявка на клиента, което може да остави URL адресите и състоянието на приложението несъгласувани.
Първоначалната HTTP заявка вече е пътувала до Squid, преди helper да може да я пренасочи. Тази политика не може да защити тази заявка със задна дата. TLS започва при следващата HTTPS връзка; само CONNECT тунел не осигурява криптиране.