เปลี่ยนเส้นทางคำขอ HTTP ที่เลือกจาก Squid ไปยัง HTTPS
ส่งคืนการเปลี่ยนเส้นทางฝั่งไคลเอนต์สำหรับไซต์ที่รู้จักซึ่งรองรับ HTTPS แทนการเปลี่ยนทุก URL ต้นทาง HTTP อย่างเงียบ ๆ หรือสมมติว่าพร็อกซีสามารถสร้างการรองรับ TLS ที่ต้นทางได้
Squid สามารถขอให้เบราว์เซอร์ลองคำขอ HTTP URL ที่เลือกใหม่ผ่าน HTTPS ปลายทางต้องให้บริการทรัพยากรที่เกี่ยวข้องผ่าน HTTPS อยู่แล้ว การรัน Squid บน Raspberry Pi ไม่ได้สร้างความสามารถนั้นที่เว็บไซต์
สำหรับอินเทอร์เฟซ url_rewrite_program ของ Squid 7 helper สามารถส่งคืนการเปลี่ยนเส้นทางฝั่งไคลเอนต์เช่นนี้:
OK status=307 url="https://www.example.com/help"
นี่คือตัวอย่างการตอบกลับ helper หนึ่งรายการสำหรับคำขอที่ตรงกัน ไม่ใช่โปรแกรม helper ที่สมบูรณ์ เบราว์เซอร์ได้รับการเปลี่ยนเส้นทางและส่งคำขอใหม่ไปยัง URL HTTPS 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 เพียงอย่างเดียวไม่ให้การเข้ารหัสใด ๆ