درخواست ارسال‌شدهٔ پراکسی را در مقصد آن مشاهده کنید
نقطهٔ مشاهدهٔ درست را برای سرایندهایی که پس از ارسال درخواست HTTP توسط کارخواه افزوده یا تغییر می‌کنند انتخاب کنید.
کارخواه یک درخواست HTTP آماده می‌کند و یک پراکسی پیشرو می‌تواند آن پیام را پیش از ارسال به جلو تغییر دهد. مقصد جایی است که نسخهٔ ارسال‌شده در آن قابل مشاهده می‌شود.
| نقطهٔ مشاهده | پیام موجود در آنجا |
|---|---|
| شیء درخواست کارخواه | درخواستی که برای نخستین گام آماده شده است |
| گزارش درخواست مبدأ یا گردانندهٔ بازتاب | درخواستی که پس از ارسال به جلو دریافت می‌شود |
| مجموعهٔ سرایندهای پاسخ در کارخواه | پاسخی که در مسیر بازگشت دریافت می‌شود |
برای بررسی کنترل‌شده، از نقطهٔ پایانی‌ای استفاده کنید که خودتان اداره می‌کنید و سرایندهای درخواست دریافتی را ثبت یا بازمی‌گرداند. به درخواست نشانه‌ای شناسایی‌شدنی بدهید تا رکورد مبدأ به عملیات مشخص کارخواه نسبت داده شود.
در برنامه‌ای مبتنی بر WebClient، ResponseHeaders پاسخ بازگردانده‌شده را توصیف می‌کند. این ثبت درخواست پراکسی به مقصد نیست. سرور می‌تواند اطلاعات درخواست را در بدنهٔ پاسخ خود بازتاب دهد، اما این رفتار برنامه است.
اگر مسیر چند واسطه داشته باشد، مقصد اثرهای ترکیبی ارسال به جلوی آن‌ها را می‌بیند. صرف وجود یک سرایند تغییر را به گام مشخصی نسبت نمی‌دهد. برای فیلدهای سفارشی API، قواعد ارسال به جلو و فیلد Connection توضیح می‌دهند که چه زمانی تغییر انتظار می‌رود.
یک تونل معمولی HTTPS CONNECT مرز دیگری می‌افزاید: درخواست HTTP درونی میان کارخواه و وبگاه رمزنگاری شده است. پراکسی رله نمی‌تواند آن سرایندهای رمزنگاری‌شده را ویرایش کند. سرایندهای تبادل CONNECT به همان تبادل جداگانه تعلق دارند، در حالی که پراکسی بازرسی TLS مدیریت‌شده نقشی دیگر دارد.