كيف يتعامل الوكيل الأمامي مع ترويسة API مخصّصة

يمكن لواجهة API أن تحمل إصدارها في حقل طلب مخصّص مثل API-Version. ولا ينبغي لوكيل تحويل عادي أن يطرح ذلك الحقل لمجرد أن اسمه غير مألوف. فبروتوكول HTTP يوجب تحويل الحقول غير المعروفة ما لم ينطبق استثناء محدّد أو سياسة مُهيّأة.

حقل Connection هو أحد تلك الاستثناءات. قارن بين هذين الطلبين التوضيحيين:

API-Version: 2026-10
Connection: keep-alive

هنا لم يُعيَّن حقل API على أنه محلي لهذا الاتصال. وفي المثال التالي يغيّر المُرسِل نطاقه صراحةً:

API-Version: 2026-10
Connection: API-Version

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

حدّد النقطة التي يتغيّر عندها الحقل

قارن الطلب الذي بناه العميل، والحقول التي تلقّاها الوكيل وحوّلها، وما وصل إلى الأصل. فقد يحذف العميل ترويسة قبل أن يراها الوكيل؛ وقد يزيلها مُرشِّح مُهيّأ عن قصد؛ وقد يرفض الخادم طلبًا لتجاوزه حدّ الترويسات.

لا تستنتج الحذف الصامت من مجرّد عتبة لحجم الترويسة وردت في نشر قديم. فالحدود وسلوك الرفض يخصّان المكوّنات والتهيئة الفعلية. واحفظ استجابة HTTP والسجلات ذات الصلة مع الملاحظة.

في HTTPS من طرف إلى طرف داخل نفق CONNECT عادي لا يستطيع الوكيل قراءة حقل API الداخلي وحذفه انتقائيًا. وعندئذٍ يقع فحص الترويسات عند طرفي TLS أو عند وسيط فحص موثوق به صراحةً.