پاسخی که از طریق پروکسی دریافت می‌شود می‌تواند یک Location نسبی برگرداند:

Location: ../new/

HTTP مدرن در اینجا یک ارجاع URI را مجاز می‌داند. آن را نسبت به URLی که پاسخ را تولید کرده حل کنید. اگر آن URL https://docs.example/catalog/old/ بود، ارجاع بالا https://docs.example/catalog/new/ را مشخص می‌کند. نام میزبان پروکسی مبنای کار نیست.

برای درخواست‌های معمولی Python urllib از گرداننده تغییر مسیر آن استفاده کنید، نه از به هم چسباندن رشته‌ها در اطراف نقطه پایانی پروکسی:

opener = build_opener(ProxyHandler({
    "https": "http://proxy.example:8080",
}))
with opener.open("https://docs.example/catalog/old/",
                 timeout=15) as response:
    final_url = response.geturl()

برای این درخواست سند عمومی بدون احراز هویت پروکسی، یک نامزد HTTP از فهرست پروکسی HTTP می‌تواند وقتی مسیر مجاز است جایگزین نقطه پایانی نمونه شود. کلاس‌ها از urllib.request می‌آیند. گرداننده عادی آن تغییر مسیرهای پشتیبانی‌شده را در محدوده خود دنبال می‌کند. final_url URL نهایی منبع را توصیف می‌کند، نه واسطه‌ای که برای رسیدن به آن استفاده شده است.

اول حل کنید، سپس مسیر بعدی را انتخاب کنید

یک تغییر مسیر می‌تواند میزبان یا طرح مقصد را عوض کند. بنابراین سیاست پروکسی مبتنی بر مقصد باید آن URL جدید را نیز ارزیابی کند. مسیری که برای میزبان اول کار می‌کرد ممکن است مسیر میزبان بعدی نباشد.

وقتی مدیریت تغییر مسیر را خودتان پیاده‌سازی می‌کنید، از حل ارجاع URI با پردازش قطعه‌های نقطه‌ای استفاده کنید. قواعد متد کد وضعیت واقعی را حفظ کنید و یک محدودیت تغییر مسیر اعمال کنید. افزودن Location به نام میزبان جایگزین آن الگوریتم حل نیست.

اگر تغییر مسیر شکست خورد، URL درخواستی، وضعیت پاسخ، مقدار Location و URL بعدی حل‌شده را نگه دارید. این چهار مقدار معمولاً نشان می‌دهند که خطا به ساخت URL مربوط است یا به اتصالی که پس از آن امتحان شده است.

مقالات مرتبط