Squid ਤੋਂ ਚੁਣੀਆਂ HTTP ਬੇਨਤੀਆਂ ਨੂੰ HTTPS ਉੱਤੇ ਰੀਡਾਇਰੈਕਟ ਕਰੋ

Squid ਬ੍ਰਾਊਜ਼ਰ ਨੂੰ ਚੁਣੀ HTTP URL ਨੂੰ HTTPS ਰਾਹੀਂ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਲਈ ਕਹਿ ਸਕਦਾ ਹੈ। ਮੰਜ਼ਿਲ ਨੂੰ ਪਹਿਲਾਂ ਹੀ ਸੰਬੰਧਿਤ ਸਰੋਤ HTTPS ਰਾਹੀਂ ਪ੍ਰਦਾਨ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ; Raspberry Pi ਉੱਤੇ Squid ਚਲਾਉਣਾ ਵੈੱਬਸਾਈਟ ਉੱਤੇ ਉਹ ਸਮਰੱਥਾ ਨਹੀਂ ਬਣਾਉਂਦਾ।

Squid 7 ਦੇ url_rewrite_program ਇੰਟਰਫੇਸ ਲਈ, 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 ਬੇਨਤੀ helper ਦੁਆਰਾ ਰੀਡਾਇਰੈਕਟ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਹੀ Squid ਤੱਕ ਪਹੁੰਚ ਚੁੱਕੀ ਹੈ। ਇਹ ਨੀਤੀ ਉਸ ਬੇਨਤੀ ਨੂੰ ਪਿਛਲੇ ਪਾਸੇ ਸੁਰੱਖਿਅਤ ਨਹੀਂ ਕਰ ਸਕਦੀ। TLS ਅਗਲੇ HTTPS ਕਨੈਕਸ਼ਨ ਉੱਤੇ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ; ਸਿਰਫ਼ CONNECT ਸੁਰੰਗ ਕੋਈ ਐਨਕ੍ਰਿਪਸ਼ਨ ਨਹੀਂ ਦਿੰਦੀ।