هل يمكن لمُعيد كتابة عنوان URL في Squid تعديل أجسام الاستجابات؟
افصل اختيار عنوان URL للطلب عن تكييف الاستجابة وفك تشفير TLS عند توسيع وكيل أمامي.
يعمل url_rewrite_program على قرارات عنوان URL الخاصة بالطلب. يتلقى معلومات الطلب ويرد عبر بروتوكول المساعد في Squid؛ وهو لا يتلقى ملفًا مُنزَّلًا ليعدّله ويعيده.
| العملية المطلوبة | الحد ذو الصلة |
|---|---|
| إعادة توجيه المتصفح أو اختيار عنوان URL آخر للطلب | دور مساعد إعادة كتابة عنوان URL في مرحلة الطلب |
| تعديل جسم استجابة HTTP مرئي | أداة لتكييف الاستجابة، مثل تعديل استجابة ICAP المهيّأ |
| قراءة HTTP داخل CONNECT العادي | يجب إنهاء TLS الخاص بالوجهة أولًا ضمن ترتيب نشر مناسب |
| فك تشفير ملف مشفّر بواسطة تطبيق | تنسيق الملف وخوارزميته ومفتاحه، بصرف النظر عن وسيلة نقله |
من السهل الخلط بين الصفين الأخيرين. فالملف العادي المنقول عبر HTTPS تحميه TLS. أما الملف المشفّر بواسطة تطبيق فيمكن أن يبقى مشفّرًا حتى بعد إنهاء HTTPS. واختيار واجهة تكييف لا يوفّر مفتاح التطبيق ولا خوارزمية فك تشفيره.
ينقل CONNECT العادي بايتات نفق مشفّرة. ولا يكشف مساعد عنوان URL الاستجابة الداخلية؛ لذا يجب على أي تصميم يحتاج إلى فحص أن يحدد ما إذا كانت هذه الحركة قابلة لفك التشفير وينبغي فكها في النشر.
وحيث يستطيع Squid فحص رسالة HTTP، تظل خدمة تعديل الاستجابة مسؤولة عن ترميزات المحتوى والأطوال المتغيّرة وسلوك الفشل. اختر الواجهة بعد تعريف التحويل، بدلًا من توسيع مثال عامل لإعادة كتابة عنوان URL إلى مرحلة معالجة لا يتلقاها أبدًا.