Squid-ից ընտրված HTTP հարցումների վերահղում դեպի HTTPS
Վերադարձրե՛ք client redirect հայտնի HTTPS-ունակ կայքերի համար՝ փոխարենը լուռ փոխելու բոլոր HTTP origin URL-ները կամ ենթադրելու, որ proxy-ն կարող է origin TLS աջակցություն ստեղծել։
Squid-ը կարող է բրաուզերին խնդրել կրկնել ընտրված HTTP URL-ը HTTPS-ով։ Նպատակակետը պետք է արդեն համապատասխան ռեսուրսը մատուցի HTTPS-ով. Squid-ը Raspberry Pi-ում աշխատեցնելը այդ ունակությունը կայքում չի ստեղծում։
Squid 7-ի url_rewrite_program ինտերֆեյսի համար helper-ը կարող է վերադարձնել այսպիսի client redirect՝
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 ձևաչափի հետ։
Ընտրե՛ք client redirect, երբ բրաուզերը պետք է իմանա նոր URL-ը։ rewrite-url պատասխանը փոխարենը Squid-ից պահանջում է բերել այլ URL՝ client-ի սկզբնական հարցման հետևում, ինչը կարող է անհամապատասխան թողնել հավելվածի URL-ները և վիճակը։
Սկզբնական HTTP հարցումն արդեն հասել է Squid-ին, մինչև helper-ը կկարողանա վերահղել այն։ Այս քաղաքականությունը չի կարող հետահայաց պաշտպանել այդ հարցումը։ TLS-ը սկսվում է հաջորդ HTTPS կապում. միայն CONNECT թունելը գաղտնագրում չի ապահովում։