کیا پراکسی ناکام ہونے پر OkHttp براہِ راست جڑ جائے گا؟
یہ طے کرنے کے لیے کہ ناکام پراکسی براہِ راست رسائی کا سبب بن سکتی ہے یا نہیں، کلائنٹ ورژن، روٹنگ امیدوار اور ایپلیکیشن کا دوبارہ کوشش کا راستہ استعمال کریں۔
سسٹم HTTP پراکسی کے تاریخی معاملے میں OkHttp نے 3.5.0 میں اپنا رویہ بدلا: اس پراکسی کے ناکام ہونے کے بعد اس نے براہِ راست کنکشن کی کوشش کرنا بند کردی۔ خاموش واپسی کی پرانی رپورٹ اس تبدیلی سے پہلے کے رویے کی وضاحت کر سکتی ہے۔
وہ تاریخ ہر ایپلیکیشن کی روٹنگ پالیسی طے نہیں کرتی۔ اپنی ایپلیکیشن سے آنے والی رپورٹ کی تشریح کے لیے یہ تین جانچیں کریں:
- حل شدہ OkHttp ورژن تلاش کریں۔ کاپی کیے جا رہے نمونے کی عمر کے بجائے ایپلیکیشن کی انحصار کی معلومات استعمال کریں، بشمول وہ ورژن جو فریم ورک واقعی شامل کرتا ہے۔
- جانیں کہ یہ کلائنٹ راستہ کیسے چنتا ہے۔ واضح پراکسی اور حسبِ ضرورت ProxySelector مختلف ترتیبات ہیں۔ اگر منتخب کنندہ پراکسی کے بعد براہِ راست امیدوار فراہم کرے تو وہ براہِ راست متبادل پیش کر رہا ہے۔
- ناکامی ہینڈلر کی پیروی کریں۔ ایسا ایپلیکیشن کوڈ تلاش کریں جو کسی دوسرے کلائنٹ کے ساتھ دوبارہ کوشش کرتا ہو۔ اس متبادل کی براہِ راست درخواست پہلے کلائنٹ کے فیصلے سے باہر ہے۔
لازمی پراکسی کی ضرورت کے لیے متعلقہ کلائنٹ پالیسی کو براہِ راست متبادل پیش کرنے کے بجائے رکنا چاہیے۔ حقیقی کلائنٹ اور دوبارہ کوشش کے راستے کو اس ضرورت کے خلاف جانچیں؛ صرف 3.5.0 تبدیلی پوری مشین کے لیے ٹریفک کا قاعدہ نہیں ہے۔