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 ટનલ કોઈ એન્ક્રિપ્શન આપતી નથી.