نحوهٔ برخورد یک پروکسی پیشرو با سرآیند سفارشی 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 یا به واسطهٔ بازرسی که صریحاً مورد اعتماد است تعلق دارد.