Redirect Selected HTTP Requests from Squid to HTTPS
Return a client redirect for known HTTPS-capable sites instead of silently changing every HTTP origin URL or assuming the proxy can create origin TLS support.
Squid can ask a browser to retry a selected HTTP URL over HTTPS. The destination must already serve the corresponding resource over HTTPS; running Squid on a Raspberry Pi does not create that capability at the website.
For Squid 7’s url_rewrite_program interface, a helper can return a client redirect such as:
OK status=307 url="https://www.example.com/help"This is one illustrative helper response for a matching request, not a complete helper program. The browser receives the redirect and makes a new request for the HTTPS URL. A URL outside the upgrade policy can receive OK, leaving it unchanged.
Use a known list of HTTPS-capable destinations and parse the incoming URL. Preserve the intended path and query, account for explicit ports, and handle request methods deliberately. Blindly replacing every http prefix assumes each origin has an equivalent HTTPS service.
The helper must answer every input line using the protocol of the installed Squid version. If concurrent helper channels are enabled, preserve the channel identifier in the reply. An older bare 301:URL example is not interchangeable with the current result-and-key/value format.
Choose a client redirect when the browser should know the new URL. A rewrite-url response instead asks Squid to fetch a different URL behind the client’s original request, which can leave application URLs and state inconsistent.
The initial HTTP request has already travelled to Squid before the helper can redirect it. This policy cannot retroactively protect that request. TLS starts on the subsequent HTTPS connection; a CONNECT tunnel alone supplies no encryption.