Squid-იდან არჩეული HTTP მოთხოვნების HTTPS-ზე გადამისამართება

Squid-ს შეუძლია ბრაუზერს სთხოვოს არჩეული HTTP URL-ის ხელახლა ცდა HTTPS-ით. დანიშნულებამ უკვე უნდა მიაწოდოს შესაბამისი რესურსი HTTPS-ით; Squid-ის Raspberry Pi-ზე გაშვება ამ შესაძლებლობას საიტზე არ ქმნის.

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 მოთხოვნა უკვე მივიდა Squid-ამდე, სანამ helper შეძლებს მის გადამისამართებას. ეს პოლიტიკა ვერ დაიცავს იმ მოთხოვნას უკუქცევით. TLS იწყება შემდეგ HTTPS კავშირზე; მხოლოდ CONNECT გვირაბი დაშიფვრას არ იძლევა.