إعادة توجيه طلبات HTTP المحددة من Squid إلى HTTPS

يمكن لـ Squid أن يطلب من المتصفح إعادة محاولة عنوان HTTP محدد عبر HTTPS. يجب أن يقدّم الهدف المورد المقابل عبر HTTPS بالفعل؛ وتشغيل Squid على Raspberry Pi لا ينشئ تلك القدرة على الموقع.

لواجهة url_rewrite_program في Squid 7، يمكن لبرنامج مساعد أن يعيد إعادة توجيه للعميل مثل:

OK status=307 url="https://www.example.com/help"

هذه استجابة توضيحية واحدة لبرنامج مساعد لطلب مطابق، وليست برنامجًا مساعدًا كاملًا. يتلقى المتصفح إعادة التوجيه ويجري طلبًا جديدًا لعنوان HTTPS. وقد يتلقى عنوان خارج سياسة الترقية OK فيبقى دون تغيير.

استخدم قائمة معروفة بأهداف قادرة على HTTPS وحلّل العنوان الوارد. حافظ على المسار والاستعلام المقصودين، واحسب المنافذ الصريحة، وتعامل مع أساليب الطلب بوعي. استبدال كل بادئة http دون تمييز يفترض أن لكل أصل خدمة HTTPS مكافئة.

يجب أن يجيب البرنامج المساعد عن كل سطر إدخال وفق بروتوكول نسخة Squid المثبتة. وإذا كانت قنوات المساعد المتزامنة مفعّلة، فاحفظ معرّف القناة في الرد. مثال 301:URL القديم المجرد ليس قابلًا للتبادل مع صيغة النتيجة والمفتاح/القيمة الحالية.

اختر إعادة توجيه العميل عندما ينبغي أن يعرف المتصفح العنوان الجديد. أما استجابة rewrite-url فتطلب من Squid جلب عنوان مختلف خلف طلب العميل الأصلي، ما قد يترك عناوين التطبيق وحالته غير متسقة.

سبق أن وصل طلب HTTP الأولي إلى Squid قبل أن يتمكن البرنامج المساعد من إعادة توجيهه. لا تستطيع هذه السياسة حماية ذلك الطلب بأثر رجعي. يبدأ TLS في اتصال HTTPS اللاحق؛ ونفق CONNECT وحده لا يوفر أي تشفير.