Squid retry_on_error: קודי סטטוס ומסלולים חלופיים

ב-Squid קיימת אפשרות בשם retry_on_error, אך השם רחב מהפרשנות השימושית שלה. היא אינה אומרת שכל בקשה שנכשלה תישלח שוב ללא הגבלה עד שהדף יעבוד.

בגרסאות שתומכות בהנחיה זו, היא כבויה כברירת מחדל. רשימת השליחה החוזרת המתועדת היא 403, 500, 501, 502, 503 ו-504, והיא מנסה את הבקשה דרך יעד אחר שעובד. זה רלוונטי במיוחד בהיררכיה עם מסלולי העברה חלופיים. זה אינו רק ניסיון חוזר מתוזמן של אותו socket לאותו שרת.

תחילה תנו שם לכשל

סירוב בעת התחברות לפרוקסי, כשל אימות פרוקסי, שגיאת HTTP מהמקור ותשובה שנקטעה לאחר שהתחילה המסירה אינם מציעים את אותה הזדמנות לשליחה חוזרת. אל תצפו שהגדרה אחת תטפל בארבעתם באותו אופן.

ליציאה פרטית, החליטו גם אם מסלול חלופי מקובל. ל-parent אחר יכול להיות כתובת מקור ציבורית אחרת, מדיניות אימות אחרת או מיקום רשת אחר. הצלחה דרך החלופה עשויה להפר את הסיבה שבגללה נבחר ה-parent הראשון.

פעולות היישום מוסיפות שיקול נוסף: חזרה על בקשה עלולה לחזור על ההשפעה שלה. הלקוח והשרת זקוקים לסמנטיקה נאותה של שליחה חוזרת, במיוחד לפעולות שיוצרות או משנות נתונים. הגדרת פרוקסי אינה תחליף לטיפול ברמת היישום בתוצאות לא ודאיות.

קראו את ההנחיה עבור הגרסה המדויקת שלכם; המדריך מפרט זמינות והתנהגות ברירת מחדל. שמרו גם על מועדי הבקשה וסך ההמתנה הנראה למשתמש. ניסיון העברה נוסף עלול לבזבז את הזמן שנותר בלי להניב תוצאה טובה יותר.

בעת חקירת כשלים לסירוגין, תעדו את הסטטוס, ה-parent או היעד שנבחר ואת רצף הניסיונות. אחרת, שליחות חוזרות עלולות לגרום לבעיית ניתוב חוזרת להיראות כמו אתר איטי בדרך כלל, תוך הסתרת המסלול שנכשל בפועל.