محل یافتن هدرهای پاسخ CONNECT یک پروکسی
وقتی فیلد تشخیصی مخصوص پروکسی در شیء پاسخ مقصد وجود ندارد، تبادل CONNECT را بررسی کنید.
فیلد تشخیصی در پاسخ CONNECT پروکسی به پاسخی متفاوت از پاسخ بعدی وب‌سایت تعلق دارد. شیء پاسخ مقصد در سطح بالا ممکن است فقط دومی را نشان دهد.
| رابط انتقال | محل ظهور فراداده‌های CONNECT |
|---|---|
| API استاندارد اتصال HTTP پایتون، 3.12+ | get_proxy_response_headers() هدرهای پاسخ CONNECT را برمی‌گرداند، یا None وقتی CONNECT ارسال نشده است. |
| جمع‌آوری هدر در libcurl | هدرهای CONNECT می‌توانند گنجانده شوند. CURLOPT_SUPPRESS_CONNECT_HEADERS تحویل آن‌ها را از مسیرهای خروجی هدر مربوطه کنترل می‌کند. |
برای مدیریت cURL در Guzzle، هر بلوک پاسخ را با on_headers ثبت کنید به‌جای اینکه فقط به پاسخ بازگشتی نگاه کنید. از رابط پشتیبانی‌شده کلاینتی که واقعاً درخواست را انجام می‌دهد استفاده کنید. کتابخانه‌ای که روی پایتون ساخته شده لزوماً روش اتصال را در پاسخ خود آشکار نمی‌کند و یک نمونه اتصال جداگانه نمی‌تواند این تبادل را نشان دهد. سرکوب هدرهای CONNECT در libcurl می‌تواند تجزیه‌گر را ساده کند، اما شاهدی را که تشخیص نیاز دارد پنهان می‌کند.
اگر فیلد هنوز وجود ندارد، شرایط مستند محصول، روش و نتیجه را در اپراتور بررسی کنید. درخواست ارسال‌شده به‌صورت متن ساده و تونل مات HTTPS می‌توانند فراداده را متفاوت نشان دهند؛ فیلد فروشنده بخشی الزامی از هر پاسخ نیست.
تعریف فیلد را همراه با مقدارش نگه دارید. IP بازگشتی ممکن است شنونده، اتصال محلی، خروجی انتخاب‌شده یا مقصد را توصیف کند. شکل آن به‌تنهایی منبع رو به وب‌سایت را مشخص نمی‌کند.