Squid retry_on_error: رموز الحالة والمسارات البديلة

يوجد في Squid خيار باسم retry_on_error، لكن الاسم أوسع من تفسيره المفيد. فهو لا يعني أن كل طلب فاشل سيُعاد إلى ما لا نهاية حتى تعمل الصفحة.

في الإصدارات التي تدعم هذا التوجيه، يكون معطّلًا افتراضيًا. قائمة الإعادة الموثّقة هي 403 و500 و501 و502 و503 و504، ويجرّب الطلب عبر وجهة أخرى عاملة. هذا مهم خصوصًا في هرمية ذات مسارات تمرير بديلة. وهو ليس مجرد إعادة محاولة موقوتة عبر المقبس نفسه إلى الخادم نفسه.

سمِّ الفشل أولًا

الرفض أثناء الاتصال بوكيل، وفشل مصادقة الوكيل، وخطأ HTTP من الأصل، واستجابة قُطعت بعد بدء التسليم، لا تقدّم جميعًا فرصة الإعادة نفسها. لا تتوقع من إعداد واحد أن يعالج الأربعة على حد سواء.

بالنسبة لمخرج خاص، حدِّد أيضًا ما إذا كان المسار البديل مقبولًا. فقد يكون للوالد الآخر عنوان مصدر عام مختلف أو سياسة مصادقة مختلفة أو موقع شبكة مختلف. والنجاح عبر ذلك البديل قد يخالف سبب اختيار الوالد الأول.

تطرح عمليات التطبيق شاغلًا آخر: تكرار الطلب قد يكرّر أثره. ويحتاج العميل والخادم إلى دلالات إعادة محاولة مناسبة، لا سيما للعمليات التي تنشئ البيانات أو تغيّرها. وإعداد الوكيل ليس بديلًا عن التعامل على مستوى التطبيق مع النتائج غير المؤكدة.

اقرأ التوجيه الخاص بإصدارك بالضبط؛ فالدليل يذكر التوافر والسلوك الافتراضي. وأبقِ أيضًا مواعيد الطلب وإجمالي الانتظار المرئي للمستخدم في الاعتبار. فمحاولة تمرير إضافية قد تستهلك الوقت المتبقي دون أن تحقق نتيجة أفضل.

عند التحقيق في أعطال متقطعة، سجّل الحالة والوالد أو الوجهة المختارة وتسلسل المحاولات. وإلا فقد تجعل الإعادات مشكلة توجيه متكررة تبدو كموقع بطيء عمومًا، مع إخفاء المسار الذي فشل فعلًا.